Re: [Wonder-disc] SproutCore and WO?
Re: [Wonder-disc] SproutCore and WO?
- Subject: Re: [Wonder-disc] SproutCore and WO?
- From: Mike Schrag <email@hidden>
- Date: Mon, 16 Jun 2008 19:13:42 -0400
I do have some thoughts on stateful JSON services, though, to move
from the straight RPC route and towards a "component action" model
of services. We'll see if it works out or just makes things more
confusing :)
Although I have not yet encountered it in a commercial setting,
there is the possibility that one would like to maintain state on
the server-side in a session and aside from the session default EC.
I think the need for this is somewhat reduced in a web services
client because in many cases, the client is able to hold state, but
I can still think of cases where holding all the state in the client
would be either inefficient or impossible. Are you talking about
this sort of situation?
I had thoughts about how my "navigation destination" (ND)
architecture (discussed on Sat) with specific named endpoints might
support those sorts of workflows from a web-services client.
Essentially the HTML is replaced with a JSON-RPC client, the
stateless component controller is replaced with a stateless JSON-RPC
endpoint action and the state is stored in the ND stack.
Mind you I have only given about 10 minutes of thought to this, but
roughly, yeah, though I'm actually contemplating hijacking
WOComponents, so that your components expose actions that are
essentially JSON RPC calls. Each action would return the next
component (= next state). non-action methods (probably flagged with a
1.5 annotation) would get serialized across the wire in the response
state, and action methods would act like RPC calls. The component
request handler would be replaced by one that does JSON serialization,
or possibly some special JSON components that let you explicitly
specify the data you want to return with some convenience behaviors
for common state. Each endpoint would include a new URL for the
endpoint which would correspond to the component action url (give or
take).
What I need to explore is whether this ends up just making this MORE
complicated -- your clients need to be in sync with your server state,
but this is sort of true, anyway. Backtrack on the client would sort
of work out on its own, because when you transition to the previous
state, the client would just use the older context id. It has all the
pro's and con's of component actions (backtrack cache limits, etc),
but MAYBE it's interesting. It could also be a total disaster :) It
just seems like there's a lot of power in the WO methodology that I'm
just interested in exploring with this different front-end.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden