portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gonzalo Aguilar Delgado <gagui...@aguilardelgado.com>
Subject Re: Questions about the page manager
Date Thu, 24 Jun 2010 20:02:01 GMT
Hi Randy, 

Those are good news. This way I can flatten a little bit the model and
create nodes only for what's really used. Also the repository will be
able to check against structure to ensure that everything correct.


About caching. I think it will be best let jackrabbit do all the caching
because it support several models for this. Even better, if something
goes not fast enough I surely can write a new strategy for this.

Ok. Let's do one thing. Let me analyze node types I will need. I will
create a base implementation that works. And after that comments will be
welcome.

I really think that this can help a lot for future developments.

Thank you very much for your accessibility Randy.











El jue, 24-06-2010 a las 13:44 -0600, Randy Watler escribió:
> Gonzalo,
> 
> The implementation class hierarchy is up to you since it is hidden... 
> you just need to implement the same interfaces.
> 
> Caching is an important consideration with all of this. If you do not 
> model things with collections, you will be forced to traverse each 
> collection when it is accessed instead. The trivial implementation that 
> hits the JCR repo, RDBMS, or file system per request may not perform 
> adequately. This is why the object models are self referential instead 
> of path based.
> 
> There are also some artifacts in the DBPM that were required to map it 
> onto structures required by OJB. Obviously, those may not be necessary 
> in your implementation.
> 
> Randy
> 
> Gonzalo Aguilar Delgado wrote:
> > Hi Randy, 
> >
> > I'm working on page hierarchy. I see that there are much
> > AbstractBaseXXXX classes mixed with some Impl classes. 
> >
> > Each of them implements one kind of Interface. Ex:
> >
> > public abstract class AbstractBaseFragmentsElement extends DocumentImpl
> > implements BaseFragmentsElement
> >
> >
> > Is all this hierarchy really needed? I'm thinking about possibility of
> > flatten a little bit the structure and simplify things.
> >
> > Also I think that with jackrabbit is no longer necessary to keep
> > reference to child objects inside classes because path define childrens.
> > So no need for:
> >  private BaseFragmentElement root = null;   
> >  private FragmentElementImpl rootFragmentElementImpl = null;
> >
> > Do you think that all this is really necessary?
> >
> > Thank you.
> >
> >
> >
> >
> >
> >
> >
> > ____________________________________
> >
> >
> >
> >
> >   Gonzalo Aguilar Delgado
> >   Consultor CRM - Ingeniero en
> > Informática
> >         M. +34 607814276
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > El jue, 24-06-2010 a las 06:16 -0600, Randy Watler escribió:
> >   
> >> Hi Gonzolo,
> >>
> >> I am the PageManager "expert" if there is such a thing. See the comments 
> >> inline below.
> >>
> >> HTH,
> >>
> >> Randy
> >>
> >> Gonzalo Aguilar Delgado wrote:
> >>     
> >>> Hi David and Woonsan, 
> >>>
> >>> I've done my way to implementing the jackrabbit page manager. This will
> >>> provide:
> >>>
> >>>         Unified page managing.
> >>>         Services as WebDAV for page manager.
> >>>         Version control. 
> >>>         Repository connections (This will open doors to multisite
> >>>         manager).
> >>>         Bring unified metadata handling via jackrabbit metadata utils.
> >>>         Separate page manager logic from application.
> >>>         etc.
> >>>
> >>>   
> >>>       
> >> If you've managed all of that, you have certainly been busy!
> >>     
> >>> But I have some questions I don't really know if they are related to the
> >>> work I'm doing right now.
> >>>
> >>> 1.- When doing tests I see that Castor page manager tries to transform
> >>> source testdata when copying to target directory. Why this is done?
> >>> Because it results into the same file...
> >>>   
> >>>       
> >> It is done since the test modifies the files during execution and thus 
> >> does not operate directly on the source controlled originals. Thsi is 
> >> obviously not done with the DBPM.
> >>     
> >>> 2.- Bean manager... I'm getting crazy about how pageManager is plugged
> >>> into the Jetspeed portal. Maybe because I'm also not a Spring expert.
> >>>
> >>> [ File assembly/page-manager.xml ]
> >>>
> >>> I see two BeanReferenceFactoryBean:
> >>> xmlPageManager and dbPageManager
> >>>
> >>> That's right... The portalSite Bean has one argument to the index 0 arg
> >>> of the constructor:
> >>> <constructor-arg index="0">
> >>>       <ref bean="org.apache.jetspeed.page.PageManager" />
> >>> </constructor-arg>
> >>>
> >>> How does it knows to select if xmlPageManager or dbPageManager must be
> >>> plugged in. Does it has something to do with meta key?
> >>>   
> >>>       
> >> Jetspeed has extended the normal use of Spring to include dynamic 
> >> binding. This is indeed accomplished via the categories/meta support. 
> >> There is a properties file, I think it is names spring-keys.properties, 
> >> or something like that, it selects which bean meta keys are used at 
> >> runtime. Beans that do not match are ignored.
> >>     
> >>> I'm really lost. I debugged jetspeed and saw that for me
> >>> xmlPageManager(Castor one) is plugged in... But why? I don't find any
> >>> reference to it?
> >>>
> >>> I have to say that got a little bit lost with the bean names being fully
> >>> qualified ones. org.apache.jetspeed.portalsite.PortalSite pointed to an
> >>> Interface that got me confused until I realized that was only a name and
> >>> that real bean (impl one) got plugged instead...
> >>>
> >>> Thank you!
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ____________________________________
> >>>
> >>>
> >>>
> >>>
> >>>   Gonzalo Aguilar Delgado
> >>>   Consultor CRM - Ingeniero en
> >>> Informática
> >>>         M. +34 607814276
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> >>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >>>
> >>>
> >>>   
> >>>       
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> >> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >>
> >>     
> >
> >
> >   
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message