From: Pascal R. <pr...@ma...> - 2012-02-24 19:25:40
|
Le 2012-02-24 à 14:15, Ramsey Gurley a écrit : > > On Feb 24, 2012, at 9:20 AM, Pascal Robert wrote: > >> >> Le 2012-02-23 à 12:07, Ramsey Gurley a écrit : >> >>> If your direct action class extends ERD2WDirectAction you can >>> >>> /wa/CreatePerson >>> >>> /wa/EditPerson?__key=<PK> >>> >>> and get to an edit/inspect page. It's static, you can bookmark it. Submitting the form will be a /wo though. >> >> That's exactly the behavior that I get when using D2W components in a REST page. URL is fine until I click on Edit or Cancel. > > I've thought about this a number of times. As attractive as a direct action based D2W might be... DA2W if you will, it's not possible given the way D2W works. The stateful component architecture is required to pull it off. Just to make it clear, it does work with Ajax components. I reworked the Create Account page for wocommunity as a REST page with some AjaxObserveField and AjaxUpdateContainer (to check if the username already exists as the user types it, same thing for the email field). And I use a AjaxSubmitButton too. It works because since it's a partial submit, even if it does creation a session, but URL of the page don't change. From what I saw with ERD2WInspect, it doesn't work because the WO form is using the action binding, so a submit will change the URL (it's the same behavior if you set the action binding on a WOForm on a direct action-driven page). Using AjaxSubmitButton without setting the action binding on the form works just fine, the URL doesn't change. > Some things to consider before trying to do DA2W: > > Form field names. You'll need these to submit your values to a DA. How are you going to make them unique? On an edit page for a single EO it might not even be too hard, just use the property key. But nest related EOs two or three deep on the page and then try to come up with unique predictable names. > > Page state. How are you going to know what state the page is in? Think about an edit page with 3 embedded edit relationship pages. One might be in inline create state, one might be in inline find, and one might be in inline select. You have to pass all that back to the DA somehow. > > List state. This is really page state again, but consider everything you need to pass in the DA. Batch size, batch index, list qualifier and sort orderings? Not a trivial amount of page state to pass in a url. Especially so if there are multiple lists embedded in a page. > > All this state might be saved on the client side, but then that's something like a direct to javascript client (D2JSC)... or perhaps Gianduja. The problem there is uneven client support of everything. Don't get me started on that :-) > > Anyway, assuming Dojo or jQuery or MooTools or whatever can smooth out the browser differences, then you might be able to take the EOModel that ERRest sends down to the client and create a javascript implementation of the rule system and do component generation there. But without some special chocolate, you're stuck writing all that yourself. > > In the end, I decided to like WO for what it is. Think of it this way... fat clients are just the result of other server side frameworks having a crappy component architecture ;-) Rails, Spring, PHP ... nobody has anything like D2W. I heard seaside comes close. If they did, I'd be interested in learning about it, but AFAIK, it doesn't exist. > > Ramsey > > |