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 18:54:52 GMT
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


Mime
View raw message