Hi all,I was playing around with the Silverstripe eCommerce module to gain more insights on how the Payment module works. I realized that eCommerce is a good module but still has room for some improvements. So I decided to propose a project for GSOC 2012 to improve both the Payment and eCommerce module. Here are the project objectives:- Improve admin interface: The admin interface lacks the ability to change settings like confirmation email template, money currency, allow purchasing, etc. I don't think everybody is comfortable with modifying the config.php file every time they need to make some setting changes. Browsing, creating, and editing products are also not very user-friendly. If a store has hundreds or thousands of products, it would be very difficult for the admin to perform those tasks. So I think some improvements for the admin interface are much needed.
- Simplify installation: It took me quite a while to get the eCommerce module up and running properly. The documentation and the config.php file do not agree with each other. There are also some bugs here and there during the installation process. So I suggest we should have something like Drupal Commerce's Kickstart installation package http://drupal.org/project/commerce_kickstart. The idea is to put everything including the Payment module in one package and run an installation script that takes care of configuration, database schema as well as testing. It'd make it much easier for site owners to create an ecommerce website using Silverstripe.
- Add more features to Product: More features can be added to Product like multiple images, sales and promotion, stock availablity, etc.- Improve Payment module (taken from the GSOC project idea document): There should be an admin interface to manage payment and configure payment gateways. I haven't studied the code much, but from what I see, the APIs can be more standardized to make it easier for developers to extend the module.
- Inventory tracking & analysis: An inventory tracking system can keep track of what is in stock, what is on order, and what has been sold. An analysis & reporting system can help site owners see which items are best-sellers, how much they've earned, and how they can improve their sales. I think they are very nice features to have.
I'm new to Silverstripe, so I'm not quite sure how feasible this proposal is. I hope to receive some inputs and suggestions from everyone.Best regards,Ryan Dao
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/_iKrEw2NunUJ.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
I understand all are still being actively developed, and I'm
going to assume that it'll be up to you to choose which module you
will work with, as long as SilverStripe LTD approves.
You will be able to find a new version of e-commerce on
www.silverstrripe-ecommerce.com in the next day or two. I have done
some really exciting new work that I am testing at the moment.
We are working really hard to get a 1.0 version released. Are you a
member of silverstrip...@googlegroups.com? Make sure you are,
because all updates will be announced on there.
Cheers
Nicolaas
I'm not exactly sure of the GSOC rules, but you could always get
involved with a commerce module once Payment is improved.
Jeremy
On Tue Mar 27 12:38:46 2012, Sigurd Magnusson wrote:
> Jeremy is your question about whether you can change tack on a project
> or whether you can work on a commercial software package?
>
>
> On 27 March 2012 10:35, Jeremy Shipman <jer...@burnbright.net
> <mailto:jer...@burnbright.net>> wrote:
>
> I second Frank's recommendation to first focus on Payment.
>
> I'm not exactly sure of the GSOC rules, but you could always get
> involved with a commerce module once Payment is improved.
>
> Jeremy
>
And how can I demonstrate my competency and familiarity with Silverstripe.
Payment::set_supported_methods(array('ChequePayment' => 'Cheque Or Pay On Site'));
I think if its necessary to break backwards compatibility in order to
achieve a more ideal solution, then that should be ok. SS3 has broken
backwards compatibility, which I assume this module improvement will
fall into line with. Otherwise, yes, maintaining backwards
compatibility is good.
To help with understanding what types of payment solution there are, I
created some sequence diagrams:
https://github.com/downloads/burnbright/silverstripe-payment/PaymentsSequenceDiagram.pdf
Perhaps it would be good to document all possible features, and we can
discuss which should go into the core API.
Question: what would payment gateway unit tests look like? Won't it be
difficult to run unit tests quickly if they need to interface with
remote servers? Are there other unit tests that similarly test web apis?
One more concern I have is that the providers included with the
existing payment module became out of date, and you had to create your
own payment classes like "ImprovedPaystationPayment". My thinking is
that if we don't include any payment types in the core module, this
won't happen. On the other hand, GIT is now making it easy to manage
provider updates. Thoughts?
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverstripe-dev@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverstripe-dev@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
Yeah, I guess it's not that difficult if you're mimicking the gateway responses / requests, rather than actually connecting to them.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
> Mock requests / responses for testing sounds like a good start,
> it might be nice to have the actual requests sent if test API keys
> exist - depending on how hard it is to implement with the different
> gateways.
Perhaps create a static variable like PaymentTest::$make_external_calls,
which determines whether to use external APIs or not. False by default.
I could imagine it would be frustrating if you're developing/running tests
without an internet connection.
The best way of doing this is to create a class that is a really, really thin layer around the payment gateway. It might simply be the RestfulService class. Perhaps it's assigned to $this->gateway inside the Payment class. Then you have a setter, constructor argument, or Dependency Injection framework to specify what object should be provided to this gateway. In different parts of your application you can then pass one of 3 implementations:
1. The production service
2. The test service (but still connecting to the
3. A mock object that doesn't call anything
You don't necessarily need to have 3 separate classes - the first two might be the same class but with different properties.
If you like, you can use Phockito (or PHPUnit built-in mocking system, which I hate because of its verbosity) to create the 3rd one. Or you can hand-roll a mock object that does what your tests need it to.
#1 would be used for production deployment
#2 would be used for manual test environments and possibly automated integration testing
#3 would be used for unit tests
You might have a 4th environment, that provides a database-backed mock gateway, where that database back-end is exposed in a modeladmin. This would let you create a self-contained manual testing environment, but it means that you're testing more code that's not actually part of the production system, and it's more work. It's arguable as to whether or not this is worthwhile.
The point is that by using this dependency injection (even without a DI framework this is still dependency injection) you don't need to bake any knowledge of this stuff into your Payment class. It makes your code more testable, more maintainable, and more flexible.
Thanks, sounds good. I guess I'll need to put aside half a day to read
this thread on DI a bit more thoroughly:
http://groups.google.com/group/silverstripe-dev/browse_thread/thread/22de1481e6cc570b?fwc=2
So, just to clarify:
1. The production service connects to gateway and processes payment
as it would in a live environment
2. The test service connects to gateway and processes payment for say
a dev environment with test API account settings for the payment
gateway - or manual testing
3. Mock object represents the gateway and responds like the gateway
To unsubscribe from this group, send email to
silverstripe-d...@googlegroups.com
Briefly how they work is that they package up a result as either:
* Payment_Success - successful and not processing
* Payment_Processing - not successful and still processing - wait
* Payment_Failure - not successful and not processing
In addition these classes can contain a value, which is often just a
message. From what I've seen, these classes are only ever used in the
processPayment function.
I would also like to better understand how useful the Payment_Result classes will be moving forward.
Briefly how they work is that they package up a result as either:
* Payment_Success - successful and not processing
* Payment_Processing - not successful and still processing - wait
* Payment_Failure - not successful and not processing
"One other question, do we need to decorate Member with address fields and have sending receipts as part of this payment module?"
Regarding the $payment->Message field. It is not clear if this
is for the user to see payment information, or for admin to see
technical info such as error code. Perhaps we need also need a
PaymentMessage class to store multiple messages? Not sure.
<mailto:ma...@sunnysideup.co.nz>> wrote:
On 30 March 2012 15:17, Jeremy Shipman
<jer...@burnbright.net <mailto:jer...@burnbright.net>> wrote:
I would also like to better understand how useful the
Payment_Result classes will be moving forward.
Briefly how they work is that they package up a result
as either:
* Payment_Success - successful and not processing
* Payment_Processing - not successful and still
processing - wait
* Payment_Failure - not successful and not processing
I have just written a class for the
scnet non-hosted payment gateway. We do the soap call and
depending on what is returned from the gateway we either
return a success of a failure.
--
You received this message because you are subscribed to
the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to
silverst...@googlegroups.com
To unsubscribe from this group, send email to
silverstripe-d...@googlegroups.com
I agree: Member is not required for Payment - that's probably a good feature to support. I'm all for keeping it simple/minimal as well - address details may be a requirement for some gateways that might be something that needs looking into. If they are just optional perhaps just leave them out but support a way for developers to include address info when sending data to the gateway for example: sending address data to PayPal and it is prepopulated in the payment form that the customer is redirected to.
I definitely think common fields should go in Payment. I'm still not sold on Payment being the only class in question though. Why do you need to reference/remember the subclass, can you give an example? The way I see it, the ORM makes life a bit easier...you should only need to worry about specifically referencing subclasses when dealing specifically with that payment type. Am I missing something?If there are specific data that should be recorded for a payment for a given gateway perhaps decorate Payment? It saves you referencing and remembering the subclass but maybe there is a performance tradeoff with decorators?I think it would be good to have just the common db fields in Payment and custom fields from other submodules are added from the submodule. Also keep in mind custom form fields with validation for some of these custom fields that are required for a particular gateway.
$payment->Message I use for the error messages etc. from the payment gateway, but like Jeremy said I agree this needs to be looked at more closely. The cheque payment type puts HTML into this field but should it just be plain text and should it support multiple messages from certain gateways etc.?
I think pass/inject a controller to Payment class to handle redirection, for Paystation this would be a generic controller which would have a standardised redirect link for that Paystation account, in other instances it might be the controller of the Order/PaidObject which could provide a link and redirect to view the Order/PaidObject. Having a standard PaymentController API/Interface that developer could subclass/implement would probably be handy.
Somehow $payment->returnTo would store the passed args, and later PaymentController would use these to create a link and redirect wherever the developer wants.$controller = $this->controller;$action = 'vieworder';$id = $buyable->ID;$payment->returnTo($controller,$action,$id,$data);
Supporting recurring payments for any gateway might be difficult because of storing cc details etc.?
I also wonder where the main fork of payment should reside. I assume
we're not going to keep it in silverstripe-labs, as we should have a
nice (non labs) module by the end of it.
I was thinking we could possibly transfer ownership to whatever student
wins this project, perhaps once they have proved themselves? Then again,
the student may not have an interest, or the time to support it once
GSOC is over.
Perhaps a bigger question to ask is a political one of who will be the
maintainer, and how will future changes be made? Since the payment
module doesn't need to change much (I hope), once finished, then perhaps
the consensus-based democracy approach will work. We'd need to create
some guidelines on how changes get accepted.
http://producingoss.com/en/consensus-democracy.html
Jeremy
Jeremy
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverstripe-dev@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-dev+unsubscribe@googlegroups.com.
Would it be a good idea for the module to move to silverstripe/payment
before adding collaborators and commencing work?
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.