Hey Ralf,
For the rich-model implementation would this benefit from FDS, or
some other data-sync framework?
Regards,
Bjorn
On 06/12/2006, at 10:31 AM, Ralf Bokelberg wrote:
Though Cairngorm doesn't prevent you from creating rich models, i
think it fits better for this kind of crud application with a
rather flat model. In fact the model is little more than a cache
of serverside objects. User gesture, update cached objects, update
view.
If i was to implement a rich model, i would let the model handle
the backend directly and make the controller a real
frontcontroller, which maps usergestures to model method calls. You
could still use cairngorm framework, it's just a slight shift of
responsibilities.
Cheers,
Ralf.
On 12/5/06, Lachlan Cotter <[EMAIL PROTECTED]> wrote:
Thanks Alex,
One thing I'm looking for is validation that there is a need in
some applications to construct an object graph of sorts to describe
the model beyond an array of records to be CRUDed. Surely I'm not
alone here?
If that's the case, is there a best practice for going from value
objects delivered from a service, to first class, intelligent model
citizens in the domain? One thing I've found confusing about the
Cairngorm approach is that models and value objects seem to be
synonymous.
You thoughts?
Cheers,
Lach
On 05/12/2006, at 11:13 PM, Alex Uhlmann wrote:
there many ways to use Cairngorm. I agree with you completly, it's
of vital importance to refactor the right functionality from both,
views and commands into model objects that mean something to your
use case. Then, this functionality can also be easier unit tested. …
However how your model is going to look like depends on your
specific needs. Cairngorm doesn't tell you how to design your
custom model or your custom view. It's the infractucture around that.
My blog entries around that, which Douglas pointed out, have the
indent to show one possible route to go towards this direction.
Nevertheless, it's difficult to show that in examples, since
there's a tradeoff in completeness and complexity vs. easy to
understand examples ....and most importantly. ..time. ;)
--
Ralf Bokelberg <[EMAIL PROTECTED]>
Flex & Flash Consultant based in Cologne/Germany
