cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: XSP block status
Date Fri, 12 Mar 2004 12:31:08 GMT
Unico Hommes wrote:

> Stephan Michels wrote:
>
>> Am Mi, den 10.03.2004 schrieb Unico Hommes um 19:24:
>>  
>>
>>> There remain a few issues that need resolving.
>>>
>>> - InputModuleAction had to move along with xsp because it has a 
>>> dependency on some xsp helper class. This is unfortunate and maybe 
>>> unnecessary. Perhaps someone with more knowledge about this class 
>>> could take a look and see if they can solve this?
>>>
>>> - Source samples. Some use xsp's. Move these to xsp block or remove 
>>> them altogether?
>>>   
>>
>>
>> I'm in favour of removing them. But I can't decide that.
>>  
>>
>
> Me too. I don't think there remains an appropriate place to move them. 
> What do others think?
>
>>> - I18n samples. Needs volunteer.
>>>
>>> - simpleform samples. Needs volunteer.
>>>   
>>
>>
>> Only the first example use XSPs.
>>
>>  
>>
>>> - session-fw patches are executed before xsp patches but depend on 
>>> them. Move xsp specific stuff from session-fw to xsp.
>>>   
>>
>>
>> I think this stuff, can stay where it is. The patch mechanism should
>> now work properly.
>>  
>>
>
> Nice one! Thanks.
>
>>> - some blocks have dependencies on xsp. These need to be declared.
>>>   
>>
>>
>> I think the rest comes the paradigm shift to flow+jx early or later.
>>  
>>
>
> I was thinking more in the way that some blocks won't work when xsp is 
> not included. For instance eventcache comes to mind. I'll see what 
> more dependencies I can find.


some block _samples_ won't work is of course what you mean.

What we really need is the concept of optional dependencies.  Examples:
- during the eventcache build, the xsp samples should be copied over if 
it's optional xsp dependency is present.
- during the jms build, the xsp and database caching examples should be 
created if both those optional dependencies are present.

I have been wondering if ant 1.6 gives us some new options for these 
blocks builds which make this more possible.  for example, I think the 
new import facility would allow us to import generic block build tasks 
into the block's own (usually non-present) build.xml, avoid generating 
the blocks build via xsl, and easily add arbitrarily complex 
sub-dependencies.  Does that spark any ideas?

Geoff

Mime
View raw message