On Tue, Jul 24, 2012 at 9:43 AM, Franklin, Matthew B. <[email protected]>wrote:
> On 7/24/12 12:26 PM, "Chris Geer" <[email protected]> wrote: > > >On Thu, Jun 28, 2012 at 6:46 AM, Ate Douma <[email protected]> wrote: > > > >> On 06/28/2012 03:13 PM, Franklin, Matthew B. wrote: > >> > >>> -----Original Message----- > >>>> From: Ate Douma [mailto:[email protected]] > >>>> Sent: Thursday, June 28, 2012 8:23 AM > >>>> To: [email protected] > >>>> Subject: Re: [Proposal] Model Isolation > >>>> > >>>> On 06/28/2012 10:35 AM, Scott Wilson wrote: > >>>> > >>>>> On 28 Jun 2012, at 03:41, Chris Geer wrote: > >>>>> > >>>>> On Wed, Jun 27, 2012 at 6:50 PM, Franklin, Matthew B. > >>>>>> <[email protected]>wrote: > >>>>>> > >>>>>> Chris asked the question in the past if we wanted to move all > >>>>>>models > >>>>>>> to > >>>>>>> using IDs to reference related objects. I think this approach > >>>>>>>makes > >>>>>>> sense > >>>>>>> in certain cases and tight coupling makes sense in others. I have > >>>>>>>put > >>>>>>> together a proposal for a balanced approach in the wiki [1]. > >>>>>>> > >>>>>>> Given that each of these changes should be isolated enough, I > >>>>>>>think we > >>>>>>> > >>>>>> can > >>>> > >>>>> safely do this in trunk one class at a time. > >>>>>>> > >>>>>>> Thoughts? > >>>>>>> > >>>>>>> > >>>>>> I think we could even get away with combining Page and Widget > >>>>>>groups. > >>>>>> > >>>>> Those > >>>> > >>>>> are pretty tightly linked and probably won't be separated. > >>>>>> > >>>>>> I think I can agree with that, for now. > >>>> Although the sizing and scaling of the Page group might be > >>>>very/extremely > >>>> different from the Widget group. So separating these two might still > >>>>be > >>>> needed > >>>> or at least considered. > >>>> > >>> > >>> I think they need to be separated for the simple case that you want to > >>> define your widgets in a separate store from your pages. I can see > >>>wanting > >>> to keep Widgets in SQL while pages in a document store. Also, if you > >>>want > >>> to connect to a separate widget store like edukapp, the widget model > >>>needs > >>> to be separated. > >>> > >>> I don't see how nor do I expect Rave to externalize its widget > >>>storage, > >> even if using an external edukapp like *shop* to retrieve new (or > >>updated) > >> widget definitions. > >> > >> But as I already said I can see the need to separate the storage of the > >> widget model from the page model. So I'm also +1 to already cater for > >>that > >> need now. > >> > >> > >> > >>>> I made a small update to the group definitions: I moved the > >>>>PageTemplate* > >>>> types > >>>> to a separate Page Prototyping group. AFAIK these have nothing so > >>>>much to > >>>> do > >>>> with Page Rendering but are only used as 'prototype' when creating new > >>>> Page* > >>>> instances. Or maybe I misunderstood why the PageTemplate* types were > >>>> grouped > >>>> under Page Rendering? > >>>> > >>> > >>> Prototyping is better. I only called it Rendering because I included > >>>the > >>> layout, which is more of a runtime rendering pointer. > >>> > >>> > >>>> Anyway, I'm working on an alternate dynamic and hierarchical > >>>> PageDefinition/PageFragment model for the content-services sandbox > >>>>which > >>>> I > >>>> intend as replacement for all the Page* groups. IMO the current model > >>>> isn't > >>>> going to scale or be maintainable so *some* changes will be needed for > >>>> sure. > >>>> > >>>> > >>> It should be a good start to isolate this then, right? > >>> > >> Well, yes. Or maybe. Depends on your POV and angle you're looking at it > >>:) > >> > >> Note that the alternate PageDefinition model will need some time to > >>flesh > >> out and we're using the sandbox for that as a custom Rave extension > >>project > >> setup. > >> So we do need to sync (API wise) with changes in trunk to pick them up. > >>Or > >> we may delay that depending on the amount of flux. > >> > >> > >> > >> > How close do you think you are to proposing that model? > >> I'm currently prototyping with a bare minimal POJO model (runtime only) > >> and we also will need a HMVC controller mapping first before we can > >>start > >> executing it. > >> Next week Marijan and myself will work most or even full week on this. > >> Marijan will continue on this the week thereafter and then take a 3 week > >> holiday. > >> And I will already take a 3 week holiday after next week. > >> > >> Starting August I will pick up where Marijan left, and Marijan will join > >> the effort again in the 2nd week of August. And we intend to complete > >>the > >> majority of the work before/at the end of August. > >> > >> BTW: Ard will continue with and hopes to release next week a new/update > >> Jackrabbit OCM module, if all goes well. Thereafter he'll start working > >>on > >> a JCR persistence module for Rave using this. > >> > >> > >> I was hoping we could started on this next week at the latest... > >>> > >> Sure, why not. > >> > >> For trunk the effort in the sandbox is not yet relevant, nor should it > >> hamper it. And most/all of the Model isolation makes sense anyway, > >> regardless. > >> I only expect/hope to replace all three Page* groups with this effort in > >> the sandbox. So spending an enormous amour of time on (or better: > >>within) > >> these Model groups might be a bit wasteful. > > > > > >I went ahead and created an initial JIRA item [1] and branch [2] to start > >to work on this. After a few minutes of looking at this though I've come > >up > >with a few questions I wanted to bring up for discussion. > > Cool > > > > >1) IDs: Do we want to stick with longs for the IDs or move to a more > >generic String? If we went with String it would allow implementors a lot > >of > >variety in what they used under the covers for the ID (could still be a > >number). > > My vote would be with a generic string > > >2) Services/Repositories: It seems to make sense that if we are grouping > >things into dependent groups that there shouldn't > >be separate services/repositories for all the items inside a group. I > >updated the wiki page [3] to reflect my opinion on how we should > >restructure the services/repositories. > > I think there is definitely value in having the discussion; but, I think > we can start the work of isolation without solving it. In other words, > how to organize the code layers is important, but something that is > different than changing the model. My $0.02 > Matt, the reason I bring it up is I'm not a huge fan of circular relationships in an object model and was hoping to get rid of them. For example, Widget references a list of WidgetComments however I don't think each of those WidgetComment objects should have a reference back to the Widget. If you do, you could actually build an object model where a Widget has a Comment in it's list that has a reference to another Widget (granted, that would mean there was a error somewhere else). This doesn't mean a persistence implementation couldn't have those reverse relationships (i.e JPA) but it wouldn't be in the public model. What do you think? > > > > > >Chris > > > >> > >> > >> > >>> > >>>> One thing to consider though is how does a tightly coupled data model > >>>>>> > >>>>> work > >>>> > >>>>> for the various APIs? I've only done a little research but it looks > >>>>>like > >>>>>> the REST API returns/accepts a pretty shallow data model. Would that > >>>>>> > >>>>> cause > >>>> > >>>>> problems with a richer backend data model? > >>>>>> > >>>>> > >>>>> I think it may make sense to decouple the REST API data model from > >>>>>the > >>>>> > >>>> underlying model with some DTO classes representing just the data we > >>>>want > >>>> to expose. > >>>> > >>>>> > >>>>> Yes, agreed on that. > >>>> > >>>> Related to this, I've spend last week some time looking into the > >>>>project > >>>> Qi4j > >>>> project [1] and the underlying DDD [2], DCI [3] and CQRS [4] theory > >>>>and > >>>> practices. > >>>> > >>>> Although I think they (Qi4j) are on the right track and this > >>>>potentially > >>>> might > >>>> be good for us (Rave) to look into, I also think its a bit too much > >>>>and > >>>> to far > >>>> reaching right now to pick this up. > >>>> Nonetheless the links below are recommended to read into if your > >>>> interested. > >>>> > >>>> [1] > >>>>http://www.qi4j.org/**introduction-background.html< > http://www.qi4j.org/ > >>>>introduction-background.html> > >>>> [2] > >>>>http://en.wikipedia.org/wiki/**Domain-driven_design< > http://en.wikipedia > >>>>.org/wiki/Domain-driven_design> > >>>> [3] > >>>>http://www.artima.com/**articles/dci_vision.html< > http://www.artima.com/ > >>>>articles/dci_vision.html> > >>>> > >>>>http://en.wikipedia.org/wiki/**Data,_context_and_interaction<http://en > . > >>>>wikipedia.org/wiki/Data,_context_and_interaction> > >>>> [4] > >>>>http://martinfowler.com/bliki/**CQRS.html< > http://martinfowler.com/bliki > >>>>/CQRS.html> > >>>> > >>>> > >>>>>> Chris > >>>>>> > >>>>>> > >>>>>>> [1] : > >>>>>>> > >>>>>>> http://wiki.apache.org/rave/**ArchitectureTopics/** > >>>> > >>>>Persistence/ModelIsolation< > http://wiki.apache.org/rave/ArchitectureTopi > >>>>cs/Persistence/ModelIsolation> > >>>> > >>>>> > >>>>>>> -Matt > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>> > >[1] https://issues.apache.org/jira/browse/RAVE-729 > >[2] http://svn.apache.org/repos/asf/rave/branches/model-split > ><http://svn.apache.org/repos/asf/rave/branches/model-split> > >[3] > >http://wiki.apache.org/rave/ArchitectureTopics/Persistence/ModelIsolation > >
