cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [Ann/RFC] "Sitemap Blocks"
Date Mon, 20 Jun 2005 18:27:18 GMT
Daniel Fagerstrom wrote:
> Stefano Mazzocchi wrote:
> 
>> Yey!!
>>
>> Daniel,
>>
>> you rock! Thanks so much for your continuous work on this!
>>  
>>
> Thanks :)
> 
>> See my comments inlined.
>>
>> Daniel Fagerstrom wrote:
>>  
>>
> <snip/>
> 
>>> The super block of a block is identified by
>>> /wiring/block/connections/connection/@name='super', see
>>> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/wiring.xml?view=markup
>>>
>>> for an example.
>>>   
>>
>> hmmm, I don't get this. why do you need to explicitly identify a super
>> block? don't you get it directly thru extension?
>>  
>>
> In block.xml you identify the super block with extension. But for the
> wiring.xml you just list the connections (name and block) to the other
> deployed blocks without any indication on what role they have (requires
> or extends). For the required blocks you get a name from block.xml for
> the extended block it doesn't have (or need to have) a name in block.xml
> but it need a name in wiring.xml so I just introduced the special name
> "super".
> 
> Maybe it is not necessary to have the extended block at all in
> wiring.xml, but I prefer to have all deployment info available in
> wiring.xml. IMO it seem reasonable that if Í have a block that according
> to its block.xml extends
> http://cocoon.apache.org/blocks/another-block/1.0 it should be possible
> to deploy it so that it extends
> http://cocoon.apache.org/blocks/another-block/1.0.23.

gotcha. I don't have a problem with this.

>>> The wiring file is used by the BlocksManager to set up all the blocks.
>>> The BlocksManager is configured to point to the wiring.xml:
>>>
>>> <component role="org.apache.cocoon.components.blocks.BlocksManager"
>>>           class="org.apache.cocoon.components.blocks.BlocksManager"
>>>           file="wiring.xml"/>
>>>
>>> All access to blocks goes through the BlocksManager.
>>>   
>>
>>
>> Works for me.
>>
>>  
>>
>>> blocks: protocol
>>> ----------------
>>>
>>> The blocks mount paths from deployment should in principle be used
>>> before the main sitemap in the (main) webapp is called. But at this
>>> point I didin't want to touch the core classes e.g. o.a.c.Cocoon or let
>>> any core components depend on the block infrastrucuture. Therefore I
>>> instead created a blocks: protocol that can be used in the main sitemap
>>> to connect to the blocks system:
>>>
>>>  <map:match pattern="**">
>>>    <map:read src="blocks:/{1}"/>
>>>  </map:match>
>>>   
>>
>> Great idea! I'd like to keep going with this, because sometimes, due to
>> legacy, you might want to keep the need to position the 'block subspace'
>> as you please.
>>  
>>
> I'm not certain that I actually supported "relocation" in the current
> implementation, but it shouldn't be that hard to fix.

ok

>>> block-path: module
>>> ------------------
>>>
>>> A block URI block:foo:/bar where the foo block is mounted at /test can
>>> be "absoultized" to /test/bar by using the block-path input module,
>>>
>>>  {block-path:foo:/bar}
>>>
>>> see example in
>>> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/test1/sub/.
>>>
>>> This module can be used together with the LinkRewriterTransformer
>>> http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html
>>>
>>> from Forrest fame to creta the block link rewriting behaviour described
>>> in the end of http://wiki.apache.org/cocoon/BlocksDefinition.
>>>   
>>
>>
>> this works, but I don't think it's the prettiest thing we could do.
>>  
>>
> It wasn't designed to be pretty, it was designed to get the job done
> with a minimal amount of work ;)
> 
>> A better way of achiving link translation would be to allow the
>> LinkRewritingTransformer to be aware of href="" and src="" attributes
>> (or configurable other attributes) and make them react on the same
>> block: protocol used above.
>>
> AFAIU, the LinkRewritingTransformer doesn't have any internal knowledge
> about anything, all actual link transformation is done in imput modules
> and connected to attributes and scemes in the configuration:
> http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html.
> Highly flexible but not that easy to understand, but if we provide good
> default configuration files it shouldn't be a problem for the users.
> 
>> so the link transformer must be able to
>> access the block manager and obtain the relative URL of the given stuff.
>>  
>>
> Any component can find the current block and require it to "absolutize"
> a block: URL
> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/java/org/apache/cocoon/components/modules/input/BlockPathModule.java?view=markup,
> so it wouldn't be a problemt to write a more a specialized block aware
> link transformer.
> 
>> I would also go a little further and say that this behavior could be
>> *transparent* and part of the pipeline implementation itself, but I have
>> no strong opinion about this and I'm generally against behind-your-back
>> black magic.
>>  
>>
> I prefer to avoid black magic in this case, link rewriting is hard
> enough to understand without any "helpfull" automagics. I might change
> my mind when we have got more experience about using block link
> rewriting, maybe it is so natural so that we can make it automatic
> without confusing ourselfes, but I'd rather wait and see.

Fair enough.

>> Another thing that might be helpful here, is to allow links to be
>> 'absolutized', when, for example, they need to be (say RSS feeds) and
>> the cocoon webapp is proxied.
>>
>> Link translation is hacky today and blocks will force us to think about
>> how to do it in a better way, let's keep also proxying, absolutization
>> and session IDs in mind as well.
>>  
>>
> Agree.
> 
>> thoughts?
>>  
>>
> No ;) I think that the link rewriting that we allready have (although
> somewhat hacky) in the current block implementation, will simplify link
> handling quite a lot compared to th previous situation without blocks.
> But there is definitively more to do. If wou could write a more detailed
> analysis of link rewritiong it would be really helpfull.

no, I don't really care that much about making a change. So, I'll happy
let do-ocracy continue :-)

>                                  --- o0o ---
> 
> Now, to continue the work on the sitemap aspect of blocks we really need
> to apply it in a non trivial application. By doing that we will get more
> experience of the involved concepts. It would also make it easier for
> the rest of the community to see what the sitemap aspect of blocks can
> be used for. There seem to be a large community interest in the
> component aspect of blocks, but not yet in the sitemap aspect. Actually
> using it in a real use case would also increase my and others motivation
> to polish the implementation.
> 
> I think that the Linotype would make an excelent use case for
> introducing the current block mechanism in. Are you interested?

In fact, I am.

Give me a 3 lines description of where to start looking and I'll get going.

-- 
Stefano.


Mime
View raw message