Mailing-List: contact jetspeed-dev-help@portals.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@portals.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4C23B5A1.3060506@wispertel.net>
Date: Thu, 24 Jun 2010 13:44:33 -0600
From: Randy Watler <watler@wispertel.net>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Jetspeed Developers List <jetspeed-dev@portals.apache.org>
Subject: Re: Questions about the page manager
References: <1277372737.5112.128.camel@azul1>
	 <4C234CA9.4080208@wispertel.net> <1277405692.29400.7.camel@azul1>
In-Reply-To: <1277405692.29400.7.camel@azul1>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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