As far as I'm concerned, Lifecycle's are always a good idea. I think
you would gain on the Rapid side, since Hobo's ajax makes updating a
part (as Hobo calls it) or a snippet based view (as you call it) fairly
automatic. You'd end up with something like this:
<do part="blah">
<if test="&this.state='a'">
stuff for state a here
<transition-button transition="x" update="blah"/>
</if>
<else>
stuff for state b here
<transition-button transition="y" update="blah"/>
</else>
</do>
But even if Rapid didn't help, you should use a Lifecycle anyways. I
think state machines are as much of an advance for web app design as
REST was. It makes your conceptual design so much cleaner.
Bryan
Gregory Kornblum wrote:
I have implemented this sort of use case on a different stack with
jQuery ajax calls to a controller returning different snippet based
views and will be doing similar things on a hobo based stack which
screams for a lifecycle approach but am not sure this would prove to
be any easier on a less elegant stack.
Lets say you have a like this and you like this states based toggle
which would then be removed by a secondary toggle for 2 rsvp and
attending states and then coming back with a not attending action
which restores both back to to both an rsvp and like it.
What I am failing to see is the advantage using a using a Hobo
life cycle even though it is a generic life cycle regardless what is
used.
Yes the code would be a bit more elegant but would there be a rapid
advantage?
--
You received this message because you are subscribed to the Google Groups "Hobo
Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/hobousers?hl=en.
