I'd opt for the following solution:
1) rename all the occurrences of corresponding_po_id to correspondingPoId
2) add a chain event to call setPoNumber
Jacopo
Scott Gray wrote:
Couple of options here:
- Set the po number directly in the cart (this is done to set the po in
other methods, but there isn't much in CheckOutEvents using the cart
directly)
- have the "payment" response chain go to setPoNumber and then carry on to
calcShippingBeforePayment, but I don't think this is the best way to handle
such a simple field and I have to admit it looks like I mistakenly added
setPoNumber to ShoppingCartEvents while working on the commit
A few screens and methods relating to anonymous checkouts use the
corresponding_po_id but they aren't affecting by changing the name in this
screen. Is there a convention for field naming in forms? I only seem to
come across names like this in ftl files.
Regards
Scott
On 29/03/07, Chris Howe <[EMAIL PROTECTED]> wrote:
That will work if you change the variable name corresponding_po_id to
correspondingPoId in the templates. We then need to double check that
corresponding_po_id isn't used/expected elsewhere.
The placement of setPoNumber in the chain needs to be looked at as
well.
--- Jacopo Cappellato <[EMAIL PROTECTED]> wrote:
> Before doing this, I think that it would worth trying to chain, in
> the
> checkout events in the ecommerce's controller the call to setPoNumber
>
> <request-map uri="setPoNumber">
> <security https="true" auth="true"/>
> <event type="java"
> path="org.ofbiz.order.shoppingcart.ShoppingCartEvents"
> invoke="setPoNumber"/>
> <response name="success" type="request" value="orderentry"/>
> <response name="error" type="request" value="orderentry"/>
> </request-map>
>
> it should work
>
> Jacopo
>
> Chris Howe wrote:
> > Could someone please revert the changes made in rev 519570. This
> > breaks the storing of a customer provided PO number in ecommerce.
> > Thanks.
> >
> > ,Chris
>
>
