rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Franklin, Matthew B." <mfrank...@mitre.org>
Subject Re: [Proposal] Model Isolation
Date Tue, 24 Jul 2012 16:43:26 GMT
On 7/24/12 12:26 PM, "Chris Geer" <chris@cxtsoftware.com> wrote:

>On Thu, Jun 28, 2012 at 6:46 AM, Ate Douma <ate@douma.nu> wrote:
>> On 06/28/2012 03:13 PM, Franklin, Matthew B. wrote:
>>> -----Original Message-----
>>>> From: Ate Douma [mailto:ate@douma.nu]
>>>> Sent: Thursday, June 28, 2012 8:23 AM
>>>> To: dev@rave.apache.org
>>>> 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.
>>>>>> <mfranklin@mitre.org>wrote:
>>>>>>  Chris asked the question in the past if we wanted to move all
>>>>>>> to
>>>>>>> using IDs to reference related objects.  I think this approach
>>>>>>> sense
>>>>>>> in certain cases and tight coupling makes sense in others.  I
>>>>>>> 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
>>>>> 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
>>>> different from the Widget group. So separating these two might still
>>>> 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
>>> to keep Widgets in SQL while pages in a document store.  Also, if you
>>> to connect to a separate widget store like edukapp, the widget model
>>> to be separated.
>>>  I don't see how nor do I expect Rave to externalize its widget
>> even if using an external edukapp like *shop* to retrieve new (or
>> 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
>> need now.
>>>> I made a small update to the group definitions: I moved the
>>>> 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
>>> 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
>>>> 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
>> out and we're using the sandbox for that as a custom Rave extension
>> setup.
>> So we do need to sync (API wise) with changes in trunk to pick them up.
>> 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
>> 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
>> 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
>> 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:
>> 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
>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
>variety in what they used under the covers for the ID (could still be a

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

>>>>  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
>>>>>> 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
>>>> underlying model with some DTO classes representing just the data we
>>>> to expose.
>>>>>  Yes, agreed on that.
>>>> Related to this, I've spend last week some time looking into the
>>>> Qi4j
>>>> project [1] and the underlying DDD [2], DCI [3] and CQRS [4] theory
>>>> practices.
>>>> Although I think they (Qi4j) are on the right track and this
>>>> might
>>>> be good for us (Rave) to look into, I also think its a bit too much
>>>> to far
>>>> reaching right now to pick this up.
>>>> Nonetheless the links below are recommended to read into if your
>>>> interested.
>>>> [1] 
>>>> [2] 
>>>> [3] 
>>>> [4] 
>>>>>> Chris
>>>>>>> [1] :
>>>>>>>  http://wiki.apache.org/rave/**ArchitectureTopics/**
>>>>>>> -Matt
>[1] https://issues.apache.org/jira/browse/RAVE-729
>[2] http://svn.apache.org/repos/asf/rave/branches/model-split

View raw message