RE: Dev - Reusable form question

[Kasubaski, Matt]

Si,

I finally got around to taking a good look at this again.  Unless I'm
looking at a different screen then you're thinking of, the party manager
edit contact screen behaves the same way as the ecommerce edit contact
mech does.  IE: The save button saves the data, and reloads the screen,
and the go back button is what takes you back to the original screen.

I worked up a solution for my option 2 and once I ensure I didn't cause
any unforeseen issues, I'll post it up for the group.

Matt

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Si Chen
Sent: Wednesday, November 23, 2005 6:45 PM
To: OFBiz Project Development Discussion
Subject: Re: [OFBiz] Dev - Reusable form question

Have you looked at the editcontactmech.ftl in partymgr? A done page is
passed in as part of a URL. It is then appended to the end of the
posting URL, and that causes the re-direction after the page is done.

Si

Kasubaski, Matt wrote:

> I'm currently in the process of changing how the update address screen

> behaves and could use some help.
>
> The editcontactmech.ftl form currently has two buttons, Go Back, and
> Save. On Save, the form is submitted, the updatePostalAddress service
> is called, and the form is redisplayed on success/failure. What I want

> to do is, on success of the updating of the address, return to where
> it came from.
>
> The problem is, the form is called in a number of places, view
> profile, and checkout process being the most visible. This means that
> I can't just change the location of where SUCCESS goes in the
> controller.xml file since it will always go there.
>
> Ideally, I would want to put a variable name in the value section of
> the response, but I don't see any code that supports that.
>
> IE: NOTE: I know ${done_page} is can only be used in freemarker. It's
> an example to illustrate it's a variable in the

context/session/request

>
> <request-map uri="updatePostalAddress">
>
> <security https="true" auth="true"/>
>
> <event type="service" invoke="updatePartyPostalAddress"/>
>
> <response name="success" type="view" value="${done_page}"/>
>
> <response name="error" type="view" value="editcontactmech"/>
>
> </request-map>
>
> I see two ways of doing this:
>
> 1) Change the form name in editcontactmech.ftl to change based on what

> $done_page is defined to, then add a new request-map for each call and

> change the SUCCESS value to point to the returning page.
>
> 2) Change the SUCCESS value to a new request-map which then calls a
> new service which converts the $done_page to a result code. Then the
> request-map can have the conversions for each way the form can be
called.

>
> IE:
>
> <request-map uri="updatePostalAddress">
>
> <security https="true" auth="true"/>
>
> <event type="service" invoke="updatePartyPostalAddress"/>
>
> <response name="success" type="request" value="donePage"/>
>
> <response name="error" type="view" value="editcontactmech"/>
>
> </request-map>
>
> <request-map uri="donePage">
>
> <security https="true" auth="true"/>
>
> <event type="service" invoke="convertDonePageToResult"/>
>
> <response name="viewprofile" type="view" value="viewprofle"/>
>
> <response name="checkoutshippingaddress" type="view"
> value="checkoutshippingaddress"/>
>
> </request-map>
>
> Of the two, I prefer the second option. It's cleaner and easier to

read.
>
> Is there a better way to do this?
>
> Thanks,
>
> Matt
>
>-----------------------------------------------------------------------
-
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

Matt,

Sorry.  I thought we had solved a similar problem there, but I didn't
have a chance to look at your question closely enough.  My apologies.

Si

Kasubaski, Matt wrote:

>Si,
>
>I finally got around to taking a good look at this again.  Unless I'm
>looking at a different screen then you're thinking of, the party manager
>edit contact screen behaves the same way as the ecommerce edit contact
>mech does.  IE: The save button saves the data, and reloads the screen,
>and the go back button is what takes you back to the original screen.
>
>I worked up a solution for my option 2 and once I ensure I didn't cause
>any unforeseen issues, I'll post it up for the group.
>
>Matt
>
>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>On Behalf Of Si Chen
>Sent: Wednesday, November 23, 2005 6:45 PM
>To: OFBiz Project Development Discussion
>Subject: Re: [OFBiz] Dev - Reusable form question
>
>Have you looked at the editcontactmech.ftl in partymgr? A done page is
>passed in as part of a URL. It is then appended to the end of the
>posting URL, and that causes the re-direction after the page is done.
>
>Si
>
>Kasubaski, Matt wrote:
>
>  
>
>>I'm currently in the process of changing how the update address screen
>>    
>>
>
>  
>
>>behaves and could use some help.
>>
>>The editcontactmech.ftl form currently has two buttons, Go Back, and
>>Save. On Save, the form is submitted, the updatePostalAddress service
>>is called, and the form is redisplayed on success/failure. What I want
>>    
>>
>
>  
>
>>to do is, on success of the updating of the address, return to where
>>it came from.
>>
>>The problem is, the form is called in a number of places, view
>>profile, and checkout process being the most visible. This means that
>>I can't just change the location of where SUCCESS goes in the
>>controller.xml file since it will always go there.
>>
>>Ideally, I would want to put a variable name in the value section of
>>the response, but I don't see any code that supports that.
>>
>>IE: NOTE: I know ${done_page} is can only be used in freemarker. It's
>>an example to illustrate it's a variable in the
>>    
>>
>context/session/request
>  
>
>><request-map uri="updatePostalAddress">
>>
>><security https="true" auth="true"/>
>>
>><event type="service" invoke="updatePartyPostalAddress"/>
>>
>><response name="success" type="view" value="${done_page}"/>
>>
>><response name="error" type="view" value="editcontactmech"/>
>>
>></request-map>
>>
>>I see two ways of doing this:
>>
>>1) Change the form name in editcontactmech.ftl to change based on what
>>    
>>
>
>  
>
>>$done_page is defined to, then add a new request-map for each call and
>>    
>>
>
>  
>
>>change the SUCCESS value to point to the returning page.
>>
>>2) Change the SUCCESS value to a new request-map which then calls a
>>new service which converts the $done_page to a result code. Then the
>>request-map can have the conversions for each way the form can be
>>    
>>
>called.
>  
>
>>IE:
>>
>><request-map uri="updatePostalAddress">
>>
>><security https="true" auth="true"/>
>>
>><event type="service" invoke="updatePartyPostalAddress"/>
>>
>><response name="success" type="request" value="donePage"/>
>>
>><response name="error" type="view" value="editcontactmech"/>
>>
>></request-map>
>>
>><request-map uri="donePage">
>>
>><security https="true" auth="true"/>
>>
>><event type="service" invoke="convertDonePageToResult"/>
>>
>><response name="viewprofile" type="view" value="viewprofle"/>
>>
>><response name="checkoutshippingaddress" type="view"
>>value="checkoutshippingaddress"/>
>>
>></request-map>
>>
>>Of the two, I prefer the second option. It's cleaner and easier to
>>    
>>
>read.
>  
>
>>Is there a better way to do this?
>>
>>Thanks,
>>
>>Matt
>>
>>-----------------------------------------------------------------------
>>    
>>
>-
>  
>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>    
>>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev