You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Gonzalo Aguilar Delgado <ga...@aguilardelgado.com> on 2010/06/24 11:45:37 UTC
Questions about the page manager
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.
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...
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?
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
Re: Questions about the page manager
Posted by Gonzalo Aguilar Delgado <ga...@aguilardelgado.com>.
Hi Randy,
Great! I will check spring dynamic binding...
About implementation... I still do not provide anything ;-) But I will
try to do so.
Give me some time I hope something can be in place this week. If I get
this working
then maybe we can extend everything to provide a complete CMS system
inside jetspeed.
Thank you so much!
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
Re: Questions about the page manager
Posted by Gonzalo Aguilar Delgado <ga...@aguilardelgado.com>.
Mmmm!
I not counted on that! I suppose that jackrabbit caching will not offer
a complete solution after all as it can return different instances each
time.
I really don't know if I will be able to handle all this amount of
changes int that short time but I will try. If something looks incorrect
or not good enough let's amend it after... Let's consider this a
"incubation" project.
Thank you again Randy.
El jue, 24-06-2010 a las 14:58 -0600, Randy Watler escribió:
> Gonzalo,
>
> No doubt it is tempting to let Jackrabbit do all the caching. Beware
> though that this approach may cause problems within Jetspeed which
> requires that the same Java instance is returned for the same persistent
> object. At the moment, this holds true across multiple requests and
> users! In case you are scratching your head, yes, the object model needs
> to be thread safe and operate as if there is no transaction isolation.
> Changing this in Jetspeed represents a large amount of work which is why
> it has not been done already. Consider yourself forewarned!
>
> Randy
>
> Gonzalo Aguilar Delgado wrote:
> > 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
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: Questions about the page manager
Posted by Randy Watler <wa...@wispertel.net>.
Gonzalo,
No doubt it is tempting to let Jackrabbit do all the caching. Beware
though that this approach may cause problems within Jetspeed which
requires that the same Java instance is returned for the same persistent
object. At the moment, this holds true across multiple requests and
users! In case you are scratching your head, yes, the object model needs
to be thread safe and operate as if there is no transaction isolation.
Changing this in Jetspeed represents a large amount of work which is why
it has not been done already. Consider yourself forewarned!
Randy
Gonzalo Aguilar Delgado wrote:
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Questions about the page manager
Posted by Gonzalo Aguilar Delgado <ga...@aguilardelgado.com>.
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
Re: Questions about the page manager
Posted by Randy Watler <wa...@wispertel.net>.
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
Re: Questions about the page manager
Posted by Gonzalo Aguilar Delgado <ga...@aguilardelgado.com>.
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
Re: Questions about the page manager
Posted by Randy Watler <wa...@wispertel.net>.
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