Configuration & Settings

[Greg Moser]

Ok, this is kind of an open ended question, but I wanted to get peoples feelings on how "Configuration" would be setup on a client by client basis.  Obviously we need some format for storing things like using lbs vs kgs, USD vs EURO, UPS vs Fedex, ext...  I imagine that as the product grows the complexity of the configuration will also grow and I want to make sure that we have a solid foundation to build on.  Also a lot of the code that I am going to start writing for the front-end will rely on these configuration variables.

There are a couple of different "groupings" of these configurations that I could think of right off the bat:

1) Language & Terms Dictionary: This is where a term like "Add To Cart" would be stored so that the end user could easily change.

2) Workflow Configuration: An example might be that when an order is placed an end user could add a step to that process where an additional e-mail was sent out.

3) Extended Attributes:  Almost all end users will want to add custom UDF's to things like products or customers.

4) Simple Settings: This would be things like which 3rd party payment gateway to use along with the credentials, or potentially which shipping provider to use.

I'd like to hear any ideas that people might have, or any other methods that you've seen work well.  I'd like to get this going ASAP in hopes to have a methodology setup by end of next week.

-Greg

[Tony G]

Well, as far as configuring for different languages, I envisioned it
being handled by resource bundles. So just like there are resource
bundles for different languages for the Mura admin, there would
be .properties files for all the text in the plugin and then the user
would be able to set the locale to one of the available languages in
order to translate all the text in the app. So that means instead of
hardcoding "Add To Cart" it would actually say something like
#application.rbFactory.getKeyValue(session.rb,"slatwall.addToCart")#.
The only thing I'm not sure of is if there's support for plugin-
specific resource bundles in Mura. I know you can put a resource
bundle into a theme, but I'm not sure about plugins.

On Jan 18, 7:03 pm, Greg Moser <gregjmo...@gmail.com> wrote:
> Ok, this is kind of an open ended question, but I wanted to get peoples
> feelings on how "Configuration" would be setup on a client by client basis.
>  Obviously we need some format for storing things like using lbs vs kgs, USD
> vs EURO, UPS vs Fedex, ext...  I imagine that as the product grows the
> complexity of the configuration will also grow and I want to make sure that
> we have a solid foundation to build on.  Also a lot of the code that I am
> going to start writing for the front-end will rely on these
> configuration variables.
>
> There are a couple of different "groupings" of these configurations that I
> could think of right off the bat:
>

> 1) *Language & Terms Dictionary: *This is where a term like "Add To Cart"

> would be stored so that the end user could easily change.

> 2) *Workflow Configuration*: An example might be that when an order is

> placed an end user could add a step to that process where an additional
> e-mail was sent out.

> 3) *Extended Attributes:*  Almost all end users will want to add custom

> UDF's to things like products or customers.

> 4) *Simple Settings*: This would be things like which 3rd party payment

[Sumit Verma]

Yes, we should definitely use the standard implementation of i18n. Here is good implementation example of it:

http://trac.mach-ii.com/machii/wiki/Internationalization

We will need to modify our validation framework a little bit to follow i18n as well. Pretty much there shouldn't be any hard coded text that will display on the front-end.

Besides that we will need other locale specific setting such as currency format, time format, number format, measurement unit (ISO vs Metric), address format (zip/postal, phone number). I'm sure there are lot of other stuff that I'm missing. It will be good to start documenting what we want to do now vs later. More info here: http://en.wikipedia.org/wiki/Internationalization_and_localization

For workflow, I think we need to have some fixed options for having different UI workflow. Here are some options:

- Single address shipping

- Multiple address shipping with address book

- Guest account checkout (no password/account)

May be few other combination.

Outside of that, stuff like sending email and adding step after order should be added using plugin event hook "onSlatwallOrderComplete". Some of these event can accept content as return variable, so user can override the standard content. Same as how mura does it for form submission.

Not sure what you mean by UDF for product and customer? Do you mean custom data fields? We already talked about doing that for products, we can think about customer as well. Mura allows you to extend user profile, may be look at that?

We will definitely need a settings table to store all king of settings. The table will just need settingName and settingValue. On the admin side, I imagine it being mostly drop downs and some text box. Some of the setting could be used to hide/display certain feature. I think this is one area that will evolve as we go.

Once everyone has chance to think about all this, may be we can have a call to discuss later this week.

HTH

Sumit Verma
Partner / Vice President | ten24, LLC
office: 877.886.5806 x 103 | mobile: 617.290.8214
www.ten24web.com | www.linkedin.com/in/sverma | twitter: blogonria

[Glyn Jackson]

I am so glad Greg has starting this question. My major concern is
focused around settings in particularly payment gateways. Everything
that has been posted above should centre around the gateway
requirements and differences between countries. How these providers
accept currency, units of measurement, tax and card security will need
to be decided by the system first. Display options i.e. currency etc
should follow naturally from these systems.

I agree with Sumit and implementation of i18n would be good, how this
fits into the gateway providers is even more important and needs to be
decided on before any work starts.

I think first before deciding on settings you need to look at how
payment gateways work. This should help us decide how Slatwall uses
and stores these settings.

I would like the approach of a module gateway, allowing developers
like myself to integrate our preferred payment provider directly into
Slatwall, but I cannot see how this would work. Our own API maybe?

How can Slatwall amalgamate all this information in a generic way?

If I wanted to use SagePay as my UK payment provider, they offer 3
options. form post, server and direct. they require you to send over
the currency (Euro, GBP etc), postcode, shipping address, CSV code and
a transaction code. As is mandatory in most EU countries, some
credit card providers such as VISA need the merchant to be in the
"Verified by VISA Scheme". This gives Slatwall more issues. Not only
the initial post and redirect URL need to be dealt with, but
intermediate checks with the banks, then the required action to be
taken i.e. continue the payment or reject etc.

On top of that you have Tax (or VAT in the UK). Different EU countries
have different taxation rates. Then to complicate things most
countries have different tax bands for different types of products.
For example, books, children's shoes and food are tax at a different
rate. Most gateway providers will require tax rates to be sent over
and calculated for them.

Now this is only one gateway, PayPal, WorldPay etc all offer different
ways to integrate and require different settings from Slatwall.

Each payment gateway provider is different. They all offer their own
API and have different syntax for processing credit cards. If we are
not carefully and don't plan the system settings around how we handle
these types of systems, we may find ourselves with the same old
ecommerce systems. Locked into a few systems and reinventing the wheel
everything is not something I would be very happy to use.

If you look at something like cfpayment, it has been designed to bring
a lot of these system together. If I look at a typical gateway here
are the most common settings I see in ecommerce stores.



• Company Name
• Send HTML e-mails - most providers will sent a separate email to you
or the customer confirming the transaction. This is typical in form or
server type integration but not with direct (everything is handled by
you)
• Currency - currect is normally sent to providers in the format of
USD, GBP etc
• Type – Payment types such as payment, deferred, refund, void etc


If you ever want to look at a ssytem which does all this very well
look at Mels. not from a developing point but from a settings point...
http://www.mals-e.com/processors.php

how can one system work with for many payment gateways, product
options etc? Now mals works with ANY cart system. I would love for
Slatwall to become that sort of system down the line.

Have a look at the admin with the details below. http://www.mals-e.com/
then view cart setup tab.

Username : 83256944
Password : AN52079

This is the level of setting Slatwall should be providing.

:)

[Sumit Verma]

Shipping, tax and CC processing is certainly something which everyone will want to have a different spin on.

I think all those needs to be set as modules, you pass certain data in and expect certain data out. It's kind of a black box. The application doesn't care what happens inside it. Now if we set it up as convention based, then it will allow developers to just drop in their custom module and we can just instantiate and use that object. 

I have implemented multiple CC processing (PayPal,cardsevices,Authorize.net) in application this way in the past and it worked well. I haven't done anything for international processor, but, I'm assuming it shouldn't be too different.

Shipping should be easy as we will just have different API for different shipping provider.

Tax is the same, but we will need tax database for other countries. I guess developer from different country may have to implement their own taxation rules.

Sumit Verma
Partner / Vice President | ten24, LLC
office: 877.886.5806 x 103 | mobile: 617.290.8214
www.ten24web.com | www.linkedin.com/in/sverma | twitter: blogonria

[Glyn Jackson]

yes the modular approach is what I think best fits CC processing.

Shipping, can it be based on a set of rules? i.e. not using an
external provider.

Tax, how would these rules be set? back to the question of settings,
did you have a quick look at mels and the cart setup? you will need to
login.

On Jan 19, 4:25 pm, Sumit Verma <sumit.ve...@ten24web.com> wrote:
> Shipping, tax and CC processing is certainly something which everyone will
> want to have a different spin on.
>
> I think all those needs to be set as modules, you pass certain data in and
> expect certain data out. It's kind of a black box. The application doesn't
> care what happens inside it. Now if we set it up as convention based, then
> it will allow developers to just drop in their custom module and we can just
> instantiate and use that object.
>
> I have implemented multiple CC processing (PayPal,cardsevices,Authorize.net)
> in application this way in the past and it worked well. I haven't done
> anything for international processor, but, I'm assuming it shouldn't be too
> different.
>
> Shipping should be easy as we will just have different API for different
> shipping provider.
>
> Tax is the same, but we will need tax database for other countries. I guess
> developer from different country may have to implement their own taxation
> rules.
>
> Sumit Verma
> Partner / Vice President | ten24, LLC

> office: 877.886.5806 x 103 | mobile: 617.290.8214www.ten24web.com|www.linkedin.com/in/sverma| twitter: blogonria

> > Have a look at the admin with the details below.http://www.mals-e.com/

[Glyn Jackson]

I am not setting mels is good by the way. I just like the config
settings in the admin they have. US or EU clients everything seems to
fit. would be nice if Slatwall had this soft of config settings.

[Glyn Jackson]

sorry....

you know sometimes I really wish I would read what I type! lol. I
blame it on typing to fast :)

[Greg Moser]

Ok, here are some key points that I derived from all the comments above:

A) Resource Bundles will be utilized in a standard i18n setup similar to how Mura works.  Hopefully we will be able to piggy back on the existing resource bundle setup of mura, and if not maybe this is something we can ask BR to add support for.

B) The one issue that Sumit brought up about how validation will change when utilized in different countries is something that we need to look at more closely.  Maybe we could get some scenarios going, because there is a difference between the language that end users use in the admin which will be handled with Resource Bundles, and validation for things like shipping address & phone numbers.

C) For all of the general settings some type of "Settings" table needs to be setup with settingName and settingValue, and I am proposing a possible "grouping" of those settings by using dot notation for the settingName.  For example getSetting("units.Currency") or getSetting("units.Weight") or getSetting("checkout.AllowGuest").

D) We need to be able to easily extend the attributes of Products & Accounts, which can be done very similarly to how mura does it.  Can we use the existing class extension manager for this?  Does it make more sense to build our own? Are there any other object that we need to possibly extend?

E) Versatile payment processing is extremely important for Slatwall to thrive as Glyn pointed out so clearly.  In addition a website may need to use multiple payment processing gateways.  I agree with Sumit that these should work as a "Black Box" type of component.  My idea would be that we have a designated folder called something like "PaymentGateways", this folder would contain a series of folders like "AuthorizeNet", "PayPal", "CardServices", ext.  Then in the administrator you tell Slatwall what payment methods you would like to accept and the gateway it should use for each method.  For Example:

AMEX = AuthorizeNet

MasterCard = AuthorizeNet

Visa = AuthorizeNet

PayPal = PayPal

GiftCard = XYZGiftCardGateway

In addition, an end user would be able to drop as many gateway folders they would like into the "PaymentGateways" folder.  Those would now automatically become options in the admin to use as gateways.  I envision that any of the "gateway" folders would have a mandatory gateway.cfc that would have a handful of mandatory methods like: AuthorizePayment, ChargePayment, VerifyData, ext.  And those methods would always expect an argument like an individual payment object that contains all of the standard and necessary information.  Also, in any of the "gateway" folders there would possibly be a settings.xml file that specified all of the information needed to run the gateway such as MerchantID, username, password, ext similar to how the plugin's config.xml file works.  The Slatwall administrator would then have a configuration page just like when you install a plugin into mura where all of the settings can be set and saved in an XML file for the gateway to use.

F) Shipping options also need to be easily configurable.  For this I feel like we can do something almost identical to Payment Gateways where shipping providers like FedEx or UPS could just be a folder that contains a gateway.cfc with some standardized methods.  These might all sit in a folder called "ShippingGateways".  Each gateway can also have a config.xml for the settings it requires.  The only addition is that we will need to also build in an option for end users to create their own custom rate tables through the administrator based on price or weight, but that is pretty straight forward.  From the administration point of view you would setup your shipping methods very similarly to how you setup your payment methods.

G) Taxes are very interesting piece.  We will most likely want to have the ability for some 3rd party tax calculation services like "Avatax", and again this can be done in the same fashion as both Shipping & Payments.  However most people will not be using a 3rd party provider because most businesses have relatively simple tax requirements.  I have setup a system for Nytro that is both simple and mirrors the way that taxes are typically accessed.   Basically you have a DB record for each type of tax that you would like to access.  The columns include all of the shipping address fields as well as all of the billing address fields.  Most taxes at least in the US are accessed by Shipping Address.  For example at Nytro we charge 8.25% for shipments to CA, and an additional .50 for all orders to San Diego County.  Basically the DB has 1 row with the countryCode of 'US', stateCode of 'CA', and a taxRate of 8.25% with all other fields left blank.  Then another 180 records one for each of the Postal Codes in San Diego County with a taxRate of .50%.  At checkout it runs the shipping address over this table and adds any rows that match in criteria.  This gives the most granular control over taxes possible, and if we were to ad a field for "productTaxType" we could then apply at a product x address level which gives total control.  Obviously each product would have the ability to have "productTaxType" manually set.  We could even include a field for "productType" if people can do their taxes based on that.

H) Customs & Duties for international shipments weren't brought up, but I feel like modeling it directly after the Shipping Gateways that I proposed would work perfectly.  There are 3rd party companies that provide customs estimates, but some people again just might want to set up some flat rates similar to how taxes would work.

I) Workflow changes is something that I know Sumit and I have talked about before, but I think that we have settled on utilizing a system of event hooks that allow custom developers to write whatever they would like in the way of workflow manipulation.  However, where the end developer writes that code is something that we haven't put any thought into yet I don't think.  Maybe there is a base eventHandler, that is extended in a blank file almost exactly how Mura does it for sites and themes.

J) Custom Integration with Inventory management systems isn't something that we have talked about here, but it has been already address in the existing Slatwall framework.  I just wanted to add it to this list so that we have a record of everything.

Wow, lots to think about... these are just my first attempts to get them all written out so we can tackle all of them, one at a time.  The above list can be boiled down into this list of main ideas:

A) Multi-Language Support

B) Validation Differences per Location

C) General Configuration Settings

D) Extended Attributes

E) Payment Methods

F) Shipping Methods

G) Tax Calculation

H) Customs & Duties Calculation

I) Workflow Modification

J) Custom Systems Integration

Hopefully this helps to get our thoughts organized.

-Greg