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: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
