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:
I started last week a very big project where we decided to use the MG framework as rendering engine.
The site will have a huge traffic and will need to display many 'heavy portlets' different by user or context etc...
We started to make some test and investigations on how we could implement pur rendering architecture using the MG view caching system. In short time we discovered that the cache declaration based on the include tag was not processed and considered by the framework.
The final result of our research job was that the only caching support "really" working was the once on the initial event object ( basically the first event called in a new request ).
This was a killer, not for the MG caching system per se ( we use an adapter to ehCache ) but because we completely needed to remove MG from the project. We then decided to make some more test and in a short time we could create a patch that allow MG to cache views based on the declarations made in any single include xml tag.
will create a cache copy for 3600 seconds of the view based on the value of the id argument.
Please note that any keys looks for value into the event object so, if you want to use sessionid as a cache key, you should push that into the event object on request start. Following a Sean Corfield suggestion the generate key now also consider the host where the view is processed, so If you run the same application from differents domains any domain generate a different cache.
We send code to Dan Wilson that is the MG maintainer for review and testing.
If you want to use and test ( do not use that in production cause is really not tested code ) downlaod the patch and replace the file /ModelGlue/gesture/eventrequest/EventContext.cfc.
Send your feedback ( or share on MG mailing list ).
I have worked quite hard in the last period with an interesting xhtml rendering 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 document ( and more formats ) .
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....
I was just worried about the source doc cause that must be a perfectly valid xml document. Sometimes, depending on how the string to be parsed is generated, respecting the strict xml rules can be difficult.
I then discovered that Railo ships an htmlFormat() function that is capable to "repair" your bad html and gives you back a nice xhtml format.
Look at this example:
This is a very bad html piece of code saved into a variables and parsed into htmlParse()
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.
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 ....
I decided to play around with cfwheels cause I was amazed by some examples I saw around and I have to admit is good fun.
After 1 hr testing I realized that no ioc support is build into cfwheels and ..... I really cannot live with no Ioc container available at any time so I decided to add a plugin for managing a beanFactory into cfwheels.
Probably is not the best cfwheel plugin ever written but was very easy and painless. While I tend to be very OO guy I am amazed by conventions in last period ( I am also playing with Sean Corfield FW1 ). While I am also an happy user of Coldbox and ModelGlue I find that sometimes frameworks added complexity also to easy tasks. From here my desire to look into frameworks that make of conventions their core basement.
In my mind conventions means less code in default situations and about this cfwheels and fw1 at the moment are the best. Btw I also think that for a more complex task Coldbox really has something more to help development of more advanced applications.
You can find the plugin here to play with it and have a look to cfwheels.
I am a big coldbox fan and I am very glad to post about the release of the ColdBox Book. I am ordering a copy for me and, if you are serious about coldbox, I strongly recomend it.
Coldbox has always been very well documented and the book will surely be an interesting way to go deeply into coldbox framework.
The most interesting news is the complete refactor of the UI tags. RailoAjax library now provide bridges classes that need a speficic adapter to perform the action required. This allows to switch between one library support to another with no need to change the core code.
Once the concrete implementation is done ( the Ext cfwindow is already done ) you can choose the library using the cfajaximport tag.
<cfajaximportlibrary="ext/>
Having implemented a bridge pattern for any UI implementation has also allowed us to provide a set of new events provided directly by the Railo.Events engine that do not rely on the specific implementation making code even more portable. The following event has been added :
Window.beforeCreate
Window.afterCreate
Window.beforeShow
Window.afterShow
Window.beforeHide
Window.afterHide
Window.beforeClose
Window.afterClose
Layout.afterTabSelect
Layout.beforeTabInit
Layout.afterTabInit
Layout.beforeTabCreate
Layout.afterTabCreate
Layout.beforeTabRemove
Layout.afterTabRemove
Layout.beforeTabSelect
Layout.afterTabSelect
Layout.beforeTabDisable
Layout.afterTabDisable
Layout.beforeTabEnable
Layout.afterTabEnable
What is usefull is that these events will always be usable in the same way not depending by the the tag concrete implementation. So If I need to listen to a window hide event and I have choosed the ext implementation I can use both the following syntax:
The RailoLayout.js package has already been rewritten with the default jquery implementation.
Version 0.5.2 will allow ui tags to receive an options arguments called 'args'. This struct will be converted into json and pushed into the implementation init method. In this way any config defined by the jquery or ext apis will become available. I am also working on a start for cfmap implementation.
I am quite interested in what is happening in jQuery for the next 2 weeks. 
I started last week a very big project where we decided to use the MG framework as rendering engine. 
I decided to play around with