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.
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
[2] http://en.wikipedia.org/wiki/Domain-driven_design
[3] http://www.artima.com/articles/dci_vision.html
http://en.wikipedia.org/wiki/Data,_context_and_interaction
[4] http://martinfowler.com/bliki/CQRS.html
Chris
[1] :
http://wiki.apache.org/rave/ArchitectureTopics/Persistence/ModelIsolation
-Matt
