cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
Date Fri, 07 Oct 2005 15:04:54 GMT
Berin Loritsch wrote:

<snip what="interesting explanation"/>

> Where CRACK is Better
> ---------------------
> Ruby on Rails is highly HTML centric.  That's ok because 80% of all 
> web applications are HTML centric.  However, we can leverage a 
> convention that they started in a more powerful way.  In addition to 
> the normal View conventions, Rails also has the concept of a layout.  
> You can apply the same layout to all the views in your application.  
> Now, remember that I said that Rails doesn't support extensions 
> (.html, .png, etc.).  We can set up a set of layouts that are 
> essentially the finishing pipeline for the application.  By specifying 
> a generic page markup we can provide default layouts, but the 
> convention would work like this:
>
> * The layout has a base name such as "site" which is how the layout 
> would be specified in the controller.
> * The XSLT layout naming convention would be {name}2{ext}.xsl, and we 
> would automatically select the serializer mapped to the {ext} name.
>  - Example: login/index.html using the "site" layout would transform 
> the standard markup using the "site2html.xsl" file and use the "html" 
> serializer.
>  - This allows us to also render a "site2pdf.xsl" using the "pdf" 
> serializer for /article/show/3.pdf


Funny, I just wrote something similar for my current project (simplified 
as it's a form pipeline):

<map:match pattern="view-*">
  <map:generate src="{1}.jx"/>
  <map:select type="resource-exists">
    <map:when test="style/page-{1}.xsl">
      <map:transform src="style/page-{1}.xsl"/>
    </map:when>
    <map:otherwise>
      <map:transform src="style/style.xsl"/>
    </map:otherwise>
    <map:serialize/>
  </map:select>
</map:match>

What that means is that all pages are using the common "style.xsl" 
stylesheet except if a specific "page-xxx.xsl" file exist. It then 
overrides the common styling.

Define this selector and transformers snippet as a virtual component and 
you have a transformer that uses convention over configuration and yet 
allows people to add some specific styling if ever needed.

> Changes to Cocoon
> -----------------
> In order to support something like this, we don't have to make 
> fundamental changes to Cocoon.  In fact, all we have to do is provide 
> an alternate Sitemap implementation that uses reflection to find the 
> controller class and build the pipeline based on the view source, the 
> layout location, etc.


We can do that right now with flowscript. Something along these lines:

<map:call function="frontend"/>

function frontend() {
    var path = cocoon.request.requestPath;
    var elements = split(path);
    if (this[path[0]]) {
        this[path[0]]();
    }
    if (!cocoon.redirector.hasRedirected) {
        cocoon.sendPage("view-" + path);
    }
}

If the controller function does not exist, or if it did not explictely 
sent a page, then we call the view.

> One of the things that would also help _emensely_ is to automatically 
> generate a 404 return response if there is no Controller/Action 
> match.  There are other things that will help in the process, but I 
> believe this is a much more usable way to get baptised into 
> Cocoon--and still leverage its power.  Because we would be using 
> convention to wire together an application, we have the power to even 
> build in some normal conventions for being browser aware by default.  
> If the end client's browser is smart enough to handle client side 
> styling then we can let it happen--with no more effort required by the 
> developer.
>
> Oh, and one more thing: we default to UTF-8 as the default encoding 
> all the way through.  There are issues with the ESQL logicsheet 
> introducing encoding errors, and a few more other locations.  Just 
> because much of the commercial industry seems to be ignoring 
> internationalization does not mean we should follow they poor example.
>
> What do you think?  Rosy picture?  BTW, I only used the name CRACK as 
> an eye catcher--I'm not expecting the final product to be named that.


I love it. Let's call it Crackoon :-P

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message