What's "OP"?

 > Cairngorm doesn't allow the model to talk to the backend.

Huh?

But yes, the hibernate adapter model also looks very attractive to me. 
There are some questions about how to implement Flex Data Management 
Services in Cairngorm - IResponder doesn't include a conflict() method. 
I know that Adobe consulting has implemented FDMS - search Flexcoders 
for "cairngorm" + "fdms" - if I recall they hadn't finalized how they 
deal with this a few months ago...

ServiceLocator includes DataServices in Cairngorm 2.1, but it still 
isn't clear (at least to me) whether there's a standard way to pass in a 
conflict() method.

Have you found your way to clarity on this, Adobe?  :-)

Douglas


-------------------------------------------------

Douglas McCarroll

CairngormDocs.org Webmaster
http://www.CairngormDocs.org

Flex Developer
http://www.brightworks.com
617.459.3840

-------------------------------------------------



Ralf Bokelberg wrote:
>
> Yes Bjorn
>
> As i understand the OP, the problem is, that in a normal Cairngorm 
> application the rich model sits on the server. What we see on the 
> client is only the part of the model, which is needed to drive the ui. 
> Now if you want to move the rich server model to the client, you have 
> to manage the fine grained interface between the model and your 
> persistence layer on the backend. This can't be handled by Cairngorm, 
> because Cairngorm doesn't allow the model to talk to the backend.
>
> So yes, using the FDS Hibernate adapter for example probably makes up 
> a good prototype of OPs problem: A client, which talks to backend via 
> the hibernate adapter. This means, we have all the business logic on 
> the client and the backend is just persistance.
>
> Cheers,
> Ralf.
>
> On 12/6/06, *Bjorn Schultheiss* <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>     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]
>>     <mailto:[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]
>>     <mailto:[EMAIL PROTECTED]> >
>>     Flex & Flash Consultant based in Cologne/Germany
>>
>
>
>
>
> -- 
> Ralf Bokelberg <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>>
> Flex & Flash Consultant based in Cologne/Germany
>  



--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/flexcoders/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/flexcoders/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[EMAIL PROTECTED] 
    mailto:[EMAIL PROTECTED]

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

Reply via email to