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-unsubscr...@portals.apache.org > >>> For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org > >>> > >>> > >>> > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org > >> For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org > >> > >> > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org > For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org
