rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: [Proposal] Model Isolation
Date Tue, 24 Jul 2012 16:26:06 GMT
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 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message