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:57:12 GMT
On Tue, Jul 24, 2012 at 9:43 AM, Franklin, Matthew B.
<mfranklin@mitre.org>wrote:

> 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
> >>>>>>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
>
>

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