getpaid + plone4

22 views
Skip to first unread message

sunew

unread,
Mar 2, 2010, 11:38:35 AM3/2/10
to getpaid-dev
Hi all

I've been following getpaid for a while, but I have not had a project
involving e-commerce until now. I'm currently fixing some bugs in
getpaid related to internationalization, creating a new danish payment
processor, and have a translation to danish ready. I would really like
to get some of the current issues in getpaid fixed soon, and are
willing to put in some time.

I might just commit some of the insignificant fixes to trunk, and post
for feedback on this list for the larger ones.

I'm freelancing for Headnet (Copenhagen, Denmark), and we have quite a
few plone 4 projects involving getpaid starting up, so its good news
with the beginning of the getpaid on plone 4 efforts. I'm willing to
put in a lot of effort to get this going.

I contributed a while back to PloneMall. And its good to see that some
of the PloneMall architectural problems are fixed in getpaid. My plone
experience goes back to 2.0.5.

A) What are the thoughts about ditching at least plone 2.5
compatibility in this process? The code could be cleaned up and
streamlined a bit while making getpaid plone 4 compatible.

B) David Glick wrote in another thread:

"Okay, I think I've sorted out the issues with the refactored getpaid
development buildout now -- bin/buildout -c 334.cfg should now work.
My solution was to make it check out all of the eggs that getpaid
requires forks of (zc.resourcelibrary, zc.table, yoma.batching, and
hurry.workflow) -- otherwise the original (and now incompatible)
versions get grabbed from PyPI.

Incidentally, this is kind of a mess. I'd love to see us take the
eggs that we've forked and rename them to getpaid.* so that we can
release them to PyPI without colliding with the original packages."

I would like to see no forks of other (non-getpaid specific) eggs.
Lets use the standard releases from pypi or we have chaos. Additional
features needed should be incorporated into those packages - or we
should make our own packages, building on top of (and still using)
those third party packages. Like plone.app.z3cform building on top of
z3c.form, and so on.

C) What's the status of merging Brandons and Mikkos branches?

I'll look into the plone4 work already committed during this week.

Do we have some sort of roadmap with version numbers for the next
releases of getpaid? How do the (if any) GetPaid version correspond to
getpaid.core / Products.PloneGetPaid? For instance, plone 4 support
from version xx, and plone 2.5 compatibility until yy.


Regards,

Sune B. Woeller

Asko Soukka

unread,
Apr 8, 2010, 10:36:48 AM4/8/10
to getpa...@googlegroups.com
On 02.03.2010 18:38, sunew wrote:
> C) What's the status of merging Brandons and Mikkos branches?

Hi,

I guess, I'm not the only one buzzled about the current feature-specific
branches and their current state & future... :)

- As far as I've understood, there was some progress for Brandon's
branches during the PyCon sprint, but eventually, they were not merged
into the trunk? Is that correct?

- I've read that Mikko's multipaymentprocessor-branches have been
upgraded to Plone4. It also seems that they are kept up-to-date with the
current trunk. Is that correct?

- Yesterday, David merged and released GetPaidForPlone4-branches (Great
thanks for you all, who did the hard work!), but the releases didn't
seem to include any features from either Brandon's or Mikko's branches?
Is that correct?

Since both Brandon's and Mikko's branches affect how custom
paymentprocessors (and/or their wizard support) should be
implemented/upgraded, decisions regarding the future directions would be
appreciated.

And after that there's a nice awaiting Sales Tax implementation (for us
Europeans) in Mikko's "miohtama-taxes"-branches, but those again are
based on Brandon's branches... :)

Finally, I'd be personally interested to enhance the current Currency
Options with "currency_formatting" option (should the currency symbol be
rendered before or after the currency value) from hannesc's branch (see:
http://groups.google.com/group/getpaid-dev/browse_thread/thread/1956c8017245532a).
Or does someone oppose it?

Best Regards,
Asko

Alberto Berti

unread,
Apr 8, 2010, 1:38:16 PM4/8/10
to getpa...@googlegroups.com
>>>>> "Asko" == Asko Soukka <asko....@jyu.fi> writes:

Asko> - As far as I've understood, there was some progress for
Asko> Brandon's branches during the PyCon sprint, but eventually,
Asko> they were not merged into the trunk? Is that correct?

yes

Asko> - I've read that Mikko's multipaymentprocessor-branches have
Asko> been upgraded to Plone4. It also seems that they are kept
Asko> up-to-date with the current trunk. Is that correct?

yes, i've also committed a buildout config to setup a plone4 environment
to use them.

Asko> - Yesterday, David merged and released
Asko> GetPaidForPlone4-branches (Great thanks for you all, who did
Asko> the hard work!), but the releases didn't seem to include any
Asko> features from either Brandon's or Mikko's branches? Is that
Asko> correct?

Yes, I think i was a "conservative" choice made by David to publish the
work already done while we come to a decision on the subject. I will
continue to backport new features from trunk to
"GetPaidForPlone4-multipaymentprocessors" branches until then.

Asko> Since both Brandon's and Mikko's branches affect how custom
Asko> paymentprocessors (and/or their wizard support) should be
Asko> implemented/upgraded, decisions regarding the future
Asko> directions would be appreciated.

Thanks fro opening (or re-opening) the discussion on this.

I agree, personally i've updated Mikko's branches beacuse i seemed the
"simplest" and more clean solution. The differences between the trunk
and multiplepaymentprocessors branches are some "insertion points" into
checkout and configuration and a registry of the payments methods.
What i failed to grasp of Brandon's branches is the reason for the
differentiation between onsite and offsite payment processors and why
there can be only one of the former active per site. If someone with
more experience of the two different solution can point out what's on
Brandon's code that is missing on Mikko's, i will volunteer on merging
the two.

Also i would like to see some bugreports cleanup. Many seems obsolete,
many are so vague that it's impossible to verify if the trunk is still
affected. Sometimes they are used to discuss stuff that goes far beyond
the subject of the bug but it's nearly impossible to track bugs recently
changed as the addition of comments doesn't seem to update the
"changed" field on bug. Can anyone with more knowledge about the project
or that is in charge of any of them update their status?


Asko> And after that there's a nice awaiting Sales Tax
Asko> implementation (for us Europeans) in Mikko's
Asko> "miohtama-taxes"-branches, but those again are based on
Asko> Brandon's branches... :)

never looked at it, my shop will sell stuff with clients that that don't
need to know anything about vat and other taxes.

Asko> Finally, I'd be personally interested to enhance the current
Asko> Currency Options with "currency_formatting" option (should the
Asko> currency symbol be rendered before or after the currency
Asko> value) from hannesc's branch (see:
Asko> http://groups.google.com/group/getpaid-dev/browse_thread/thread/1956c8017245532a). Or
Asko> does someone oppose it?

not me

Mikko Ohtamaa

unread,
Apr 8, 2010, 4:23:08 PM4/8/10
to getpa...@googlegroups.com
> "simplest" and more clean solution. The differences between the trunk
> and multiplepaymentprocessors branches are some "insertion points" into
> checkout and configuration and a registry of the payments methods.
> What i failed to grasp of Brandon's branches is  the reason for the
> differentiation between onsite and offsite payment processors and why
> there can be only one of the former active per site. If someone with
> more experience of the two different solution can point out what's on
> Brandon's code that is missing on Mikko's, i will volunteer on merging
> the two.

I think GetPaid just needs more plug-in points. User Interface plug-in
points specifically. Getpaid core is little too abstract and sometimes
feels that technology drive has taken it too far, so that it is damn
difficult to make it work the way you wish (UI / engine / non-Plone
abstraction). With Satchmo / LFS you just know where to enter your
hooks and it works.

>    Asko> And after that there's a nice awaiting Sales Tax
>    Asko> implementation (for us Europeans) in Mikko's
>    Asko> "miohtama-taxes"-branches, but those again are based on
>    Asko> Brandon's branches... :)
>
> never looked at it, my shop will sell stuff with clients that that don't
> need to know anything about vat and other taxes.

I can help to backport it to (Plone 4 ?) branch. It was not too many
files. The work was done on Brandon's branch as it was enjoying the
most of the development by the time.

I also took some shortcuts and did not taxes in so abstract way than
they were in getpaid.core, but simply allowing you to enter one value
which is VAT. I hoped to achieve something at least marginally useful
instead of making "super duper handle every special case" code.

>    Asko> Finally, I'd be personally interested to enhance the current
>    Asko> Currency Options with "currency_formatting" option (should the
>    Asko> currency symbol be rendered before or after the currency
>    Asko> value) from hannesc's branch (see:
>    Asko> http://groups.google.com/group/getpaid-dev/browse_thread/thread/1956c8017245532a). Or
>    Asko> does someone oppose it?

I think there are getpaid.core options for more rich formatting, we
just lack the settings interface to enter then. Also, I wrote some
custom code for taxes and getpaid.atshop so that there is not only
"currency formatter" but also "tax aware formatter" which knowns when
to enter taxes in the price. Then here are cases like "sale price
formatter" etc. where one could consider colors. But having a currency
symbol is a start.

-Mikko

--
Mikko Ohtamaa
mFabrik - Freedom Delivered.

Web site - http://mfabrik.com
Mobile site - http://mfabrik.mobi
Blog - http://blog.mfabrik.com

--
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpa...@googlegroups.com
To unsubscribe from this group, send email to getpaid-dev...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en

Asko Soukka

unread,
Apr 9, 2010, 5:48:15 AM4/9/10
to getpa...@googlegroups.com
On 08.04.2010 20:38, Alberto Berti wrote:
> I will continue to backport new features from trunk to
> "GetPaidForPlone4-multipaymentprocessors" branches until then.

Thanks a lot. I've already been using multipaymentprocessors on Plone3
so this is very news for me.

On 08.04.2010 23:23, Mikko Ohtamaa wrote:
>>> And after that there's a nice awaiting Sales Tax

>>> implementation (for us Europeans) in Mikko's

>>> "miohtama-taxes"-branches, but those again are based on

>>> Brandon's branches... :)
>
> I can help to backport it to (Plone 4?) branch. It was not too many


> files. The work was done on Brandon's branch as it was enjoying the
> most of the development by the time.

Now, when I look at it, it doesn't seem to have any dependencies on
Brandon's changes, so it should be trivial to backport.

On the other hand, it did have the controversial approach of replacing
built-in (but not really used) "TaxUtility-framework"... I think, I'll
still have to try the built-in tax framework myself first, and only then
come to the same conclusion and backport Mikko's approach of simple
built-in SalesTaxOptions (replacing TaxUtility) and a
PriceValuAdjuster-adapter.

I think, it's relevant to add here a link to Mikko's original post on
his taxes implementation:
http://groups.google.com/group/getpaid-dev/browse_thread/thread/e477909168a9ef2a

>>> Finally, I'd be personally interested to enhance the current

>>> Currency Options with "currency_formatting" option (should the

>>> currency symbol be rendered before or after the currency

>>> value) from hannesc's branch.


>
> I think there are getpaid.core options for more rich formatting, we
> just lack the settings interface to enter then.

I don't recall seeing any support in getpaid.core, but
Products.PloneGetPaid.interfaces.IGetPaidManagementCurrencyOptions
indeed defines a few options I don't understand:

* positive_currency_format, TextLine, "Positive Currency Format"
* negative_currency_format, TextLine, "Negative Currency Format"
* us_currency_formatting, TextLine, "US Currency Formatting"

Does anyone know, how those should be used?

Anyway, I'm open to any ideas, how to configure the formatting of price
from "$ 10.00" to "10.00 �", but without new ideas, I'm continuing to
use Hannes' approach
(http://groups.google.com/group/getpaid-dev/browse_thread/thread/1956c8017245532a,
diff included as an attachment, if those get through).

Of course, if those existing currency settings are necessary for some
add-ons, it's not necessary to remove them as Hannes has done, but just
add a one new setting (Hannes' "currency_format")... :)

Best Regards,
Asko

hannesc.diff

Asko Soukka

unread,
Apr 9, 2010, 7:16:18 AM4/9/10
to getpa...@googlegroups.com
On 09.04.2010 12:48, Asko Soukka wrote:
> On 08.04.2010 20:38, Alberto Berti wrote:
>> I will continue to backport new features from trunk to
>> "GetPaidForPlone4-multipaymentprocessors" branches until then.
>
> Thanks a lot. I've already been using multipaymentprocessors on Plone3
> so this is very news for me.

Oh, meant *good* news for me.

> (http://groups.google.com/group/getpaid-dev/browse_thread/thread/1956c8017245532a,
> diff included as an attachment, if those get through).

... and just noticed that I made a reverse diff from Hannes' changes to
the trunk just before them. Anyway, the idea comes clear :)

Best Regards,
Asko

Asko Soukka

unread,
Apr 9, 2010, 9:49:48 AM4/9/10
to getpa...@googlegroups.com
On 08.04.2010 23:23, Mikko Ohtamaa wrote:
>> "simplest" and more clean solution. The differences between the trunk
>> and multiplepaymentprocessors branches are some "insertion points" into
>> checkout and configuration and a registry of the payments methods.
>
> I think GetPaid just needs more plug-in points. User Interface plug-in
> points specifically. Getpaid core is little too abstract and sometimes
> feels that technology drive has taken it too far, so that it is damn
> difficult to make it work the way you wis.

Btw, is there some specific reasons, why installing and configuring
multiple payment processes must be totally different from installing and
configuring multiple shipping methods/services?

Of course, this is a bit theoretical questions, since there is not many
shipping plugins available. But since I spent my afternoon trying to
understand how getpaid.ups installs its using getpaid.core's
IPluginManager and makes its configuration available using
PloneGetPaid's ISettingsShipmentManager, I must ask, why the same
approach on payment processor configuration (ISettingsPaymentManager)
was abandoned?

:)

-Asko

Mikko Ohtamaa

unread,
Apr 9, 2010, 11:05:49 AM4/9/10
to getpa...@googlegroups.com
>
> Of course, this is a bit theoretical questions, since there is not many
> shipping plugins available. But since I spent my afternoon trying to
> understand how getpaid.ups installs its using getpaid.core's IPluginManager
> and makes its configuration available using PloneGetPaid's
> ISettingsShipmentManager, I must ask, why the same approach on payment
> processor configuration (ISettingsPaymentManager) was abandoned?

Because when I asked fellow Plone developers how settings should be
done they told me to stick with portal_properties until plone.registry
is complete. I really didn't understand ISettingsPaymentManager by the
time and thus I steered away with it, trying to stick something more
understandable.

Storing settings as annotations in the site root is bad because the
settings are "invisible" - i.e. the user has no way to access, except
magically guess Python code in Zope debug shell, if things go borked.

I believe Alberto rewrote this bit for Plone 4 branch so it should not
be an issue anymore. In long term, i think that GetPaid can start
utilizing plone.registry and try to decrease the amount of GetPaid
specific code. This concerns at least form wizards also.

Alberto Berti

unread,
Apr 9, 2010, 12:14:01 PM4/9/10
to getpa...@googlegroups.com

Asko> Of course, this is a bit theoretical questions, since there is
Asko> not many shipping plugins available. But since I spent my
Asko> afternoon trying to understand how getpaid.ups installs its
Asko> using getpaid.core's IPluginManager and makes its
Asko> configuration available using PloneGetPaid's
Asko> ISettingsShipmentManager, I must ask, why the same approach on
Asko> payment processor configuration (ISettingsPaymentManager) was
Asko> abandoned?

Mikko> Because when I asked fellow Plone developers how settings
Mikko> should be done they told me to stick with portal_properties
Mikko> until plone.registry is complete. I really didn't understand
Mikko> ISettingsPaymentManager by the time and thus I steered away
Mikko> with it, trying to stick something more understandable.

I don't get the point of ISettingsPaymentManager, it seems like a marker
interface and derives from IViewletManager, so this suggests to me that
it was intented to be used to organize visual aspects of settings that
belongs to payments? It's declared in Products.PloneGetPaid.interfaces
and isn't used anywhere else in PloneGetPaid. Is there any other
products which uses it?

Mikko> Storing settings as annotations in the site root is bad
Mikko> because the settings are "invisible" - i.e. the user has no
Mikko> way to access, except magically guess Python code in Zope
Mikko> debug shell, if things go borked.

Using utilities seems equally obscure to me, in zope2.... but i must say
it has been some time since my last zope2 project so maybe i' missing
something.

Mikko> I believe Alberto rewrote this bit for Plone 4 branch so it
Mikko> should not be an issue anymore. In long term, i think that
Mikko> GetPaid can start utilizing plone.registry and try to
Mikko> decrease the amount of GetPaid specific code. This concerns
Mikko> at least form wizards also.

I have simply moved the enabled_processors field out of
portal_properties and added it to IGetPaidManagementPaymentOptions along
with other payments setting fields (allow_anonymous_checkout,
use_ssl_for_checkout, accepted_credit_cards). Sadly, this means that now
enabled_processors is indeed stored in an annotation, but it's at least
stored the same way as other settings. Anyway, I can refactor all that
to use a persistent utility, it this is the preferred taste.

azazel

rafael

unread,
Apr 9, 2010, 12:24:25 PM4/9/10
to getpa...@googlegroups.com
Has getpaid.paypal beenm tested with Plone 4?

I am waiting this to have some ground for testing getpaid.pagseguro. As
I took getpaid.paypal as a model, I am waiting getpaid.paypal to be
updated so I can see what needs to be changed for getpaid.pagseguro..


David Glick

unread,
Apr 9, 2010, 12:28:55 PM4/9/10
to getpa...@googlegroups.com, rafael
I haven't tested getpaid.paypal, but looking through it quickly I don't
see anything that should be a problem. Why don't you just try
getpaid.pagseguro and see what (if anything) breaks? You can always ask
for help here if you get stuck.
David

Tim Knapp

unread,
Apr 9, 2010, 3:11:46 PM4/9/10
to getpa...@googlegroups.com

Yeah, it overrides the whole checkout page and just sends the user off
to the PayPal website so shouldn't really require much updates at all. I
need to make some time to look at this too.

-Tim

> David
>


Asko Soukka

unread,
Apr 12, 2010, 4:11:54 AM4/12/10
to getpa...@googlegroups.com
On 09.04.2010 19:14, Alberto Berti wrote:
>>> ISettingsShipmentManager, I must ask, why the same approach on
>>> payment processor configuration (ISettingsPaymentManager) was
>>> abandoned?

>
> I don't get the point of ISettingsPaymentManager, it seems like a marker
> interface and derives from IViewletManager, so this suggests to me that
> it was intented to be used to organize visual aspects of settings that
> belongs to payments? It's declared in Products.PloneGetPaid.interfaces
> and isn't used anywhere else in PloneGetPaid. Is there any other
> products which uses it?

Correct, ISettingsXXXManager's are only about generating configuration
panes for plugins. ISettingsPaymentManager is defined next to
ISettingsShipmentManager but, AFAIK, only the latter is used. Although,
there remains a portion of commented out code in
PloneGetpaid/browser/admin.py for the former also.

ISettingsShipmentManager is successfully used at least in getpaid.ups.

Originally, I was wondering, if there exists a working pluggable
configuration viewlet architecture for multiple shipment plugins, why it
was not used also with configuration of payment processors?

>> should not be an issue anymore. In long term, i think that

>> GetPaid can start utilizing plone.registry and try to

>> decrease the amount of GetPaid specific code. This concerns

>> at least form wizards also.

Is there any consensus on which parts of getpaid should be fully
independent from Plone? I see that the original desing has been to keep
the architecture of getpaid.* fully independent from Plone (or
Products.PloneGetPaid), but since Products.PloneGetPaid is the only
GetPaid implementation, none of the plugins really work without it.

The independent way seems to be storing settings on local persistent
utilities. Let me explore getpaid.ups as an example:

- getpaid.ups provides a local persistent utility called UPSRateService,
which implements IShippingRateService from getpaid.core

- UPSRateService both handles the business logic and stores the settings

- UPSRateService is registered by UPSPlugin, which implements
IPluginManager from getpaid.core and is run on IStoreInstalledEvent from
getpaid.core (it seems that there originally was plans to have a gui for
installing and uninstalling plugins by other means than listening
IStoreInstalledEvent)

- Finally, getpaid.ups defines UPSSettings browser:viewlet for
ISettingsShipmentManager from Products.PloneGetPaid for
displaying and managing settings using SettingsViewletManager
architecture from Products.PloneGetPaid (I guess, this is the
only part, which makes getpaid.ups dependent on
Products.PloneGetPaid and this can fixed by adding a simple
condition into ZCML-configuration)

Best Regards,
Asko

Christopher Johnson

unread,
Apr 15, 2010, 10:09:55 AM4/15/10
to getpa...@googlegroups.com
Hi folks,

Catching up on the thread here...

Sune, thanks for volunteering to help with GetPaid, the branches and upgrades! FYI, we announced stopping support for Plone 2.5 after the 0.6.2 release, so cleanup that enhances Plone 4 support (while keeping Plone 3 support) is welcome!

Great to see the enthusiasm and discussion from others too! 

Re PyCon sprint: we reviewed both Brandon and Mikko's branches. We discussed Brandon's being very close to ready to merge into trunk, but needed some additional tests. Comments on the multipaymentprocess branch are captured here: 

Regarding bug cleanup, I agree it could use some more. Anyone want to volunteer to help manage the tracker? I can help to transfer knowledge about what I may know, but it really needs some regular love.

One idea I wanted to float is some additional coordination/sprinting time to deal with all the branches and upgrades in motion. Are others open to some sprints on GetPaid during the next Plone Tuneup Day? I believe that would be April 30. That should give us some time to do additional communication (ie who is doing what, wants to do what), cleanup (issue tracker), etc.

-c

--
Cofounder and CEO
ifPeople - Innovation for People
www.ifpeople.net
t: 678-608-3408
130 Boulevard NE, #6
Atlanta, GA 30312

Asko Soukka

unread,
Apr 15, 2010, 11:30:33 AM4/15/10
to getpa...@googlegroups.com
Christopher Johnson kirjoitti 15.4.2010 kello 17.09:
> FYI, we announced stopping support for Plone 2.5 after the 0.6.2 release, so cleanup that enhances Plone 4 support (while keeping Plone 3 support) is welcome!

Hi,

as some already noticed, I recently created "a yet another multipayment branch" (branches/atsoukka)...

Actually, I'm going to experiment with multiple things: trying to embrace getpaid.core's "plugin support" (though still supporting primarily GenericSetup), creating payment processors as local persistent utilities instead of adapters, storing settings on plone.registry (when it exists), adapting Mikko's sales tax ideas on getpaid.core's current interfaces, trying to implement checkout wizard using collective.z3cform.wizard and re-design user interfaces to rely heavily on viewlets (as already used e.g. with shipping plugin settings; Mikko called for easy-to-use plug-in points and broader use of custom ViewletManagers could be one solution).

Because this might take a few months, please, try to ignore my branches and don't let them interfere with your work integrating Brandon's and Mikko's branches into the current stable design :)

I can't promise anything, of course, because, my main goal is to create a flexible and heavily integrated Plone(4)-based e-commerce solution to my employer (until the end of this year). Still, I hope, that I manage to create something, which will eventually benefit also the community.

Best Regards,
Asko

rafael

unread,
Apr 17, 2010, 3:26:24 PM4/17/10
to getpa...@googlegroups.com
Anyone has worked on this? Variations for products such as size and colour.

I've asked it i year ago and I am still wanting to have this working.

I can work sometime on this, but maybe we should together define what
would the best solution be..

Mikko Ohtamaa

unread,
Apr 17, 2010, 4:02:11 PM4/17/10
to getpa...@googlegroups.com
Hi Rafael,

> Anyone has worked on this? Variations for products such as size and colour.
>
> I've asked it i year ago and I am still wanting to have this working.

I created simple variation support for getpaid.atshop product which
provides shop items as AT content types.

The code is available at GetPaid repository. Only trunk, there has
been no releases.

-Mikko

>
> I can work sometime on this, but maybe we should together define what
> would the best solution be..
>
>
> --
> GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
> You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
> To post to this group, send email to getpa...@googlegroups.com
> To unsubscribe from this group, send email to getpaid-dev...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/getpaid-dev?hl=en?hl=en
>



--
Mikko Ohtamaa
mFabrik - Freedom Delivered.

Web site - http://mfabrik.com
Mobile site - http://mfabrik.mobi
Blog - http://blog.mfabrik.com

rafael

unread,
Apr 17, 2010, 4:43:53 PM4/17/10
to getpa...@googlegroups.com
Thanks a lot Mikko,

It will sure be usefull.. Iĺl take a look If there is anything I can do
to contribute to this product I will.. Maybe fix what in the todo list
is setted as hardcoded...

Rafael

Mikko Ohtamaa

unread,
Apr 17, 2010, 4:49:21 PM4/17/10
to getpa...@googlegroups.com
Hi Rafael,
>
> It will sure be usefull.. Iĺl take a look If there is anything I can do
> to contribute to this product I will.. Maybe fix what in the todo list
> is setted as hardcoded...

There is currently zero site using getpaid.atshop, but if you want to
give it a go I can help you with setting it up for you.

-Mikko
--
Mikko Ohtamaa
mFabrik - Freedom Delivered.

Web site - http://mfabrik.com
Mobile site - http://mfabrik.mobi
Blog - http://blog.mfabrik.com

rafael

unread,
Apr 17, 2010, 5:39:17 PM4/17/10
to getpa...@googlegroups.com
Hi Mikko,

I will create a new test plone instance and have only getpaid and
atshop installed...
Is there any special setup needed?
For what I've read in readme I will have 1 new content item that I
shall combine with a portlet. Are those ready avaible?
So I would just need to mark this item as shippable?
That simple?

Thanks,

Rafael

Mikko Ohtamaa

unread,
Apr 17, 2010, 5:48:22 PM4/17/10
to getpa...@googlegroups.com
Hi Rafael,

>  I will create a new test plone instance and have only getpaid and
> atshop installed...
>    Is there any special setup needed?

I don't remember.

>    For what I've read in readme I will have 1 new content item that I
> shall combine with a portlet. Are those ready avaible?
>   So I would just need to mark this item as shippable?
>    That simple?

README might be out of date. There will be different content items for
normal shoppable item and one with variations.

You don't use marker interfaces with getpaid.atshop. If you need a
special content item, I suggest subclassing the existing classea and
adding required interfaces and adapters.

getpaid.atshop adds special "add to cart" portlet and also it adds
"checkout" link to user action bar.

-Mikko
--
Mikko Ohtamaa
mFabrik - Freedom Delivered.

Web site - http://mfabrik.com
Mobile site - http://mfabrik.mobi
Blog - http://blog.mfabrik.com

rafael

unread,
Apr 17, 2010, 5:53:19 PM4/17/10
to getpa...@googlegroups.com
Ok,

I will give it a try.. I still have to figure out how I will merge it
with my other products that use interfaces (my ecommerce is already
running)..

I will keep you informed.

Anyone willing to take this task with me? It seems an importante addon
to have products variations for getpaid..

Thanks,

Rafael

sunew

unread,
Apr 19, 2010, 11:54:46 AM4/19/10
to getpaid-dev
I do not think the approach in the patch is the correct way -
shouldn't most of this this be handled by localization, and
automatically by the chosen form package?

I can see that thousands and decimal separator are not localized.
Currently the formatting is hardcoded at several places in getpaid
(the portlets, the cart rendering etc.) (Stuff like
</th><td>%0.2f</td></tr>"%( shipping_price ) ) This should be changed.

I don't know if this is because formlib doesn't do it (it should). In
Zope 2.12 i know zope.i18n.locales is working well, z3c.form uses it -
I'm not sure about formlib.

The order of the currency symbol and the amount can easily be handled
by translation.
I have committed a translation fix on trunk, that makes the order of
the currency symbol / price translatable.

See ticket 289.

regards,

Sune B. Wøller (sunew)

On Apr 8, 4:36 pm, Asko Soukka <asko.sou...@jyu.fi> wrote:

> Finally, I'd be personally interested to enhance the current Currency
> Options with "currency_formatting" option (should the currency symbol be
> rendered before or after the currency value) from hannesc's branch (see:http://groups.google.com/group/getpaid-dev/browse_thread/thread/1956c...).
> Or does someone oppose it?
>
> Best Regards,
> Asko

Asko Soukka

unread,
Apr 19, 2010, 2:05:31 PM4/19/10
to getpa...@googlegroups.com
sunew wrote:
> I do not think the approach in the patch is the correct way - shouldn't most of this this be handled by localization, and automatically by the chosen form package?
...
> The order of the currency symbol and the amount can easily be handled by translation. I have committed a translation fix on trunk, that makes the order of the currency symbol / price translatable.

Hi,

thank you. I'll agree that the order is better (and much easier) defined by translation. It's also good to know how the thousands and decimal separators should work when possible.

rafael

unread,
May 21, 2010, 10:56:01 AM5/21/10
to getpa...@googlegroups.com
Hi Mikko,


I added getpaid.atshop to my development eggs directories. Added
getpaid.atshop both to eggs and zcml section in buildou. I also added
collective.fancyzoom there.. I could run buildout, but trying to start
the server brings this error (traceback below). I googled it but found
nothing... Any idea? Thanks Rafael

/usr/local/Plone/zeocluster/parts/client1/bin/runzope -X debug-mode=on
2010-05-21 11:31:30 INFO ZServer HTTP server started at Fri May 21
11:31:30 2010
Hostname: 0.0.0.0
Port: 8080
2010-05-21 11:31:30 INFO Zope Set effective user to "plone"
2010-05-21 11:31:35 INFO Marshall libxml2-python not available. Unable
to register libxml2 based marshallers, at least SimpleXMLMarshaller
2010-05-21 11:31:46 INFO ZEO.ClientStorage (22881) ClientStorage
(pid=22881) created RW/normal for storage: '1'
2010-05-21 11:31:46 INFO ZEO.cache created temporary cache file '<fdopen>'
2010-05-21 11:31:46 INFO ZEO.ClientStorage (22881) Testing connection
<ManagedClientConnection ('127.0.0.1', 8100)>
2010-05-21 11:31:46 INFO ZEO.zrpc.Connection(C) (127.0.0.1:8100)
received handshake 'Z308'
2010-05-21 11:31:46 INFO ZEO.ClientStorage (22881) Server authentication
protocol None
2010-05-21 11:31:46 INFO ZEO.ClientStorage (22881) Connected to storage:
('localhost', 8100)
2010-05-21 11:31:46 INFO ZEO.ClientStorage (22881) Verifying cache
2010-05-21 11:31:46 INFO ZEO.ClientStorage (22881) endVerify finishing
2010-05-21 11:31:46 INFO ZEO.ClientStorage (22881) endVerify finished
2010-05-21 11:31:47 INFO Plone Dependency
Unable to detect Zope version. Please make sure you have Zope 2.10.4 or
newer installed.
2010-05-21 11:31:48 WARNING PlacelessTranslationService Error while
compiling
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/app/locales/pl/LC_MESSAGES/zope.po


2010-05-21 11:31:48 WARNING PlacelessTranslationService Error while
compiling
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/app/locales/es/LC_MESSAGES/zope.po


2010-05-21 11:31:48 WARNING PlacelessTranslationService Error while
compiling
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/app/locales/tr/LC_MESSAGES/zope.po


2010-05-21 11:31:48 WARNING PlacelessTranslationService Error while
compiling
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/app/locales/hu/LC_MESSAGES/zope.po


2010-05-21 11:31:48 WARNING PlacelessTranslationService Error while
compiling
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/app/locales/it/LC_MESSAGES/zope.po


2010-05-21 11:31:49 WARNING PlacelessTranslationService Error while
compiling
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/app/locales/he/LC_MESSAGES/zope.po


2010-05-21 11:31:49 WARNING PlacelessTranslationService Error while
compiling
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/app/locales/zh_TW/LC_MESSAGES/zope.po


2010-05-21 11:31:49 WARNING PlacelessTranslationService Error while
compiling
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/app/locales/fr/LC_MESSAGES/zope.po


2010-05-21 11:31:49 WARNING PlacelessTranslationService Error while
compiling
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/app/locales/zh_CN/LC_MESSAGES/zope.po


2010-05-21 11:31:49 WARNING PlacelessTranslationService Error while
compiling
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/app/locales/ja/LC_MESSAGES/zope.po


2010-05-21 11:31:50 WARNING PlacelessTranslationService Error while
compiling
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/app/locales/pt_BR/LC_MESSAGES/zope.po


2010-05-21 11:31:51 INFO p4a.z2utils.patches Extending
CMFDynamicViewFTI's dynamic view support with interfaces.
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/fields.py:417:
UserWarning: You did not specify an i18n translation domain for the
'title' field in
/usr/local/Plone/buildout-cache/eggs/p4a.plonevideoembed-1.1-py2.4.egg/p4a/plonevideoembed/configure.zcml
warnings.warn(
2010-05-21 11:31:53 INFO p4a.ploneaudio.sitesetup Using
five.localsitemanager
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/fields.py:417:
UserWarning: You did not specify an i18n translation domain for the
'description' field in
/usr/local/Plone/buildout-cache/eggs/p4a.ploneaudio-1.1b1-py2.4.egg/p4a/ploneaudio/configure.zcml
warnings.warn(
/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/fields.py:417:
UserWarning: You did not specify an i18n translation domain for the
'title' field in
/usr/local/Plone/buildout-cache/eggs/p4a.ploneaudio-1.1b1-py2.4.egg/p4a/ploneaudio/configure.zcml
warnings.warn(
2010-05-21 11:31:53 WARNING plone.z3cform Monkey patching
z3c.form.term.ChoiceTerms to correctly bind fields
2010-05-21 11:31:57 ERROR Application Couldn't install Five
Traceback (most recent call last):
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py",
line 786, in install_product
initmethod(context)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/Products/Five/__init__.py",
line 28, in initialize
zcml.load_site()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/Products/Five/zcml.py",
line 53, in load_site
_context = xmlconfig.file(file)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 579, in file
include(context, name, package)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 515, in include
processxmlfile(f, context)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 370, in processxmlfile
parser.parse(src)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
107, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/xmlreader.py",
line 123, in parse
self.feed(buffer)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
207, in feed
self._parser.Parse(data, isFinal)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
348, in end_element_ns
self._cont_handler.endElementNS(pair, None)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 349, in endElementNS
self.context.end()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 544, in end
self.stack.pop().finish()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 692, in finish
actions = self.handler(context, **args)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 515, in include
processxmlfile(f, context)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 370, in processxmlfile
parser.parse(src)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
107, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/xmlreader.py",
line 123, in parse
self.feed(buffer)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
207, in feed
self._parser.Parse(data, isFinal)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
348, in end_element_ns
self._cont_handler.endElementNS(pair, None)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 349, in endElementNS
self.context.end()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 544, in end
self.stack.pop().finish()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 692, in finish
actions = self.handler(context, **args)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 515, in include
processxmlfile(f, context)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 370, in processxmlfile
parser.parse(src)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
107, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/xmlreader.py",
line 123, in parse
self.feed(buffer)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
207, in feed
self._parser.Parse(data, isFinal)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
337, in start_element_ns
AttributesNSImpl(newattrs, qnames))
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 222, in startElementNS
self.context.begin(name, data, info)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 541, in begin
self.stack.append(self.stack[-1].contained(__name, __data, __info))
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 842, in contained
return RootStackItem.contained(self, name, data, info)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 710, in contained
factory = self.context.factory(self.context, name)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 487, in factory
raise ConfigurationError("Unknown directive", ns, n)
ZopeXMLConfigurationError: File
"/usr/local/Plone/zeocluster/parts/client1/etc/site.zcml", line 14.2-14.55
ZopeXMLConfigurationError: File
"/usr/local/Plone/zeocluster/parts/client1/etc/package-includes/017-getpaid.atshop-configure.zcml",
line 1.0-1.58
ZopeXMLConfigurationError: File
"/usr/local/Plone/zeocluster/src/atshop/getpaid/atshop/configure.zcml",
line 14.2
ConfigurationError: ('Unknown directive',
u'http://namespaces.zope.org/grok', u'grok')
Traceback (most recent call last):
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/run.py",
line 56, in ?
run()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/run.py",
line 21, in run
starter.prepare()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/__init__.py",
line 102, in prepare
self.startZope()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/__init__.py",
line 278, in startZope
Zope2.startup()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/Zope2/__init__.py", line
47, in startup
_startup()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/Zope2/App/startup.py",
line 102, in startup
OFS.Application.initialize(application)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py",
line 309, in initialize
initializer.initialize()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py",
line 338, in initialize
self.install_products()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py",
line 603, in install_products
return install_products(app)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py",
line 634, in install_products
folder_permissions, raise_exc=debug_mode)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py",
line 786, in install_product
initmethod(context)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/Products/Five/__init__.py",
line 28, in initialize
zcml.load_site()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/Products/Five/zcml.py",
line 53, in load_site
_context = xmlconfig.file(file)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 579, in file
include(context, name, package)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 515, in include
processxmlfile(f, context)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 370, in processxmlfile
parser.parse(src)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
107, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/xmlreader.py",
line 123, in parse
self.feed(buffer)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
207, in feed
self._parser.Parse(data, isFinal)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
348, in end_element_ns
self._cont_handler.endElementNS(pair, None)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 349, in endElementNS
self.context.end()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 544, in end
self.stack.pop().finish()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 692, in finish
actions = self.handler(context, **args)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 515, in include
processxmlfile(f, context)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 370, in processxmlfile
parser.parse(src)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
107, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/xmlreader.py",
line 123, in parse
self.feed(buffer)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
207, in feed
self._parser.Parse(data, isFinal)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
348, in end_element_ns
self._cont_handler.endElementNS(pair, None)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 349, in endElementNS
self.context.end()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 544, in end
self.stack.pop().finish()
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 692, in finish
actions = self.handler(context, **args)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 515, in include
processxmlfile(f, context)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 370, in processxmlfile
parser.parse(src)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
107, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/xmlreader.py",
line 123, in parse
self.feed(buffer)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
207, in feed
self._parser.Parse(data, isFinal)
File
"/usr/local/Plone/Python-2.4/lib/python2.4/xml/sax/expatreader.py", line
337, in start_element_ns
AttributesNSImpl(newattrs, qnames))
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/xmlconfig.py",
line 222, in startElementNS
self.context.begin(name, data, info)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 541, in begin
self.stack.append(self.stack[-1].contained(__name, __data, __info))
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 842, in contained
return RootStackItem.contained(self, name, data, info)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 710, in contained
factory = self.context.factory(self.context, name)
File
"/usr/local/Plone/Zope-2.10.11-final-py2.4/lib/python/zope/configuration/config.py",
line 487, in factory
raise ConfigurationError("Unknown directive", ns, n)
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File
"/usr/local/Plone/zeocluster/parts/client1/etc/site.zcml", line 14.2-14.55
ZopeXMLConfigurationError: File
"/usr/local/Plone/zeocluster/parts/client1/etc/package-includes/017-getpaid.atshop-configure.zcml",
line 1.0-1.58
ZopeXMLConfigurationError: File
"/usr/local/Plone/zeocluster/src/atshop/getpaid/atshop/configure.zcml",
line 14.2
ConfigurationError: ('Unknown directive',
u'http://namespaces.zope.org/grok', u'grok')

rafael

unread,
May 21, 2010, 11:42:34 AM5/21/10
to getpa...@googlegroups.com
Hi,

I just removed grok mention in configure.zcml and it worked... I could
add an variation item, but the portlet does not seem to work.

Is there anyone else in need of a product variation product? Should this
be an add-on product, or should it be an out-of-the box feature just as
recently added recurring payment items?

I think Mikko approach here is nice, but maybe we should not have a new
content item for this, but allow any content item be extended to a
variation item, as already it is with shippable and buyable.

I am willing to work on this in the next days, but I would be glad to
team up with someone with more experience and knowledgement of getpaid
code..

Christopher Johnson

unread,
May 21, 2010, 11:58:29 AM5/21/10
to getpa...@googlegroups.com
Hi Rafael,

I think it should be an out-of-the-box option similar to the recurring payment. ie you can use a marker interface to make something have variations. Just my 2 cents!

-c
--
Cofounder and CEO
ifPeople - Innovation for People
www.ifpeople.net
t: 678-608-3408
130 Boulevard NE, #6
Atlanta, GA 30312

rafael

unread,
May 21, 2010, 12:16:12 PM5/21/10
to getpa...@googlegroups.com
Hi,

I agree with Chris, this is a must feature for a mature e-commerce product..
 
Could we make a little sprint to add this feature. I wan't to help, but I am a little illeterate in getpaid core code, and I am not very up-to-date with the discussion about Plone 4 and the recent development of Getpaid. Anyway, having a specific to do list, I can help..

  Maybe Sunday, or another day next week? (I have a flexible schedule in work, so i can arrange myself). I think 3 or 4 of us in one day can solve this..

    Anyone avaiable?

Thanks,

 Rafael

Mikko Ohtamaa

unread,
May 21, 2010, 2:27:44 PM5/21/10
to getpa...@googlegroups.com
>
> I think Mikko approach here is nice, but maybe we should not have a new
> content item for this, but allow any content item be extended to a
> variation item, as already it is with shippable and buyable.

I suggest you rip off variation code from the content item and put it
to a separate adapter.

Also the core getpaid shopping portlet should be redesigned to support this.

-M
--
Mikko Ohtamaa
mFabrik - Freedom Delivered.

Web site - http://mfabrik.com
Mobile site - http://mfabrik.mobi
Blog - http://blog.mfabrik.com

rafael

unread,
Jul 13, 2010, 3:27:01 PM7/13/10
to getpa...@googlegroups.com
hi,

I have been thinking on how to implement this...

We have default Line items and some extensions of it as Shippable items.
(I always though this was a bit confusion, because a shippable item is a
buyable item, but ok)

So we should create a new extension

class VariableLineItem( LineItem ):

I don't know what would be a nice aproach, but there are many ways to do
this.

We could have a ViariableItem object that stores multiple ShippingItems
inside it..(I always use shippable items, because hey are more complete
than Payable items and can have attributes like weight)

I see that Mikko's approach was to create a factory that create a
payable item and then modify it. The item gets a variation code, that is
used in the cart to identify it.

Or maybe we could have this item with a dictionary storing its
prices/colours/sizes/etc , then modify the portlet to deal with it...

Anyway, I think those line just show that I don't know very well getpaid
code. So one more time I cry for a getpaid ninja help... Can we meet in
#getpaid irc to discuss how to and implement this? It sure is the most
needed feature now... And it should not be an add on product, instead
this should be out of the box...

Thanks,

rafael



Reply all
Reply to author
Forward
0 new messages