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. 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). 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. 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/ArchitectureTopics/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
