AndreaCfm

Two days ago I have posted some code that solve ( in part )  an annoying bug regarding caching in Model Glue framework.

As per MG docs the caching declaration can be used on any event-handler and include tag but, in practice. caching is only working if applied to the initial event-handler ( the first invoked by the url ). 

Since we want to use MG on our project, and we absolutely need a granular caching system, we are implementing  what we think can be a good solution and we would like to share for feedback and testings ( of course the MG team is the first in receiving our code for review and possible inclusion in future releases ).

We have made a new review to the first patch and now MG can support the following instructions:

<event-handler name="page.index">
<broadcasts />
<results>
<result do="views.one"/>
<result do="views.two"/>
<result do="template.main" />
</results>
<views>
<include name="three" template="pages/three.cfm" cache="true" />
<include name="four" template="pages/four.cfm"/>
</views>
</event-handler>

<event-handler name="views.one" cache="true"> 
<broadcasts />
....... 
<views>
<include name="one" template="pages/one.cfm" />
</views>
</event-handler> 

<event-handler name="views.two"> 
<broadcasts />
...... 
<views>
<include name="two" template="pages/two.cfm" />
</views>
</event-handler>

As you  can see from this code MG can cache a single views but , and this is the best feature I guess , is also able to cache a full event.handler even if that is not the initial event handler.

This solution can really speed up yout MG app reducing dramatically the effort you ask to your server to what your page exactly needs. Any time you are able to cache an "inner request" event MG will just include a bunch of html skipping any broadcasting and this can really save a lot of unnecessary server stress.

Over that imagine you can easily cache a full page excluding just the single lines that ( for example ) are reserved to logged user info/panel ( and of course skipping any unnecessary message broadcasting ).

You can find the patch here ( replace file /ModelGlue/gesture/eventrequest/EventContext.cfc)

Let me have your feedbacks and suggestions.

REMEMBER : THIS IS CODE SHARED FOR TESTING AND NOT FOR PRODUCTION USE.

As per my previous post about Xhtml Railo capabilities I will post my firsts experiences using Flying Saucer as enhancements of cfdocument tag.

Now, cfdocument is not bad but the rendering capabilities are quite limitated and when I discovered that cfdocument, up to cf9, do not support justified text alignment I decided to give a try with Flying Saucer.

The library works taking your xhtml and rendering that into a pdf processing your css.

I have worked quite hard in the last period with an interesting xhtmlrendering java library called "flying saucer" ( I will post more about that in the next future).

This library takes a valid xhtml string and is capable to convert it into a pdf ( and more formats ) document. What makes this lib special is the ability to format the output using css 2 and 3 stataments. And I could not imagine ahow many things css 2 and 3 is capable of....

Railo Ajax arrived to version 0.5.2.

From this release cfmap has entered into the set of tags that RailoAjax ships. Cfmap support is still experimental and do not cover event the 50% of the ACF version but development is on the way.

See more here.

Remember that the demo app that you see online is installed ( if required ) when RailoAjax deploy on your Railo server. So you can have a look to the demo code that can help you on development stage.

Another important announcment is that CFMENU is on the way to appear from a community contribution. Cfmenu has been added to 0.6 milestone ( at least in alpha version ).

Next step will be focused on docs. For a month or so the main efforts ( over cfmap implementation ) will be on dodumenting what has been done up to know keeping an eye on bugs of course.

Do not hesistate to contact me for any question and of course .... project is open ... so feel free to jump in ....