While the cfeclipse team is working on giving support to the new scripting syntax added recently in cfml I falled into something that can help someone to have a better feeeling in the meantime.

I was not aware, until yesterday, that this syntax is supported in a script based cfc:

<cfscript>
component{
   
    public String function getname(String name="Andrea"){
        return name;
    }
    public String function getlastname(String lastname="Campolonghi"){
        return lastname;
    }
}
</cfscript>

So while it does not really looks "amazing" this will give you code colouring and syntax highlighting. But, most important, the syntax is fully supported from ACF and Railo too ( did not test on OpenBD ).

Some of you will be asking why to do that ? Just use cfbuilder .... and I agree. Cfbuilder is a great tool also if , in my opinion , lack of linux support. But I am one of those who are convinced that cfml deserves an open and strong ide to attract more developers so ... if you think like me consider to donate something to cfeclipse project.

During last Sotr I was talking with Mark Drew and Micheal Offner-Streit ( the Railo cto )  and we discovered one of the many gems hidden into Railo engine.

Any cf developer has always fight with the missing support for a linked hash map in cfml. This lack has made a task  keeping a struct in a defined order. In railo you can simple do this:

<cfset str = structNew('linked') />

What you have now is a struct 100% similar to a normal struct that has the whole capabilities of a linked hash map. For example the map keep the elements into an ordered stack.

You can read more in the railo wiki docs.

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.

 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.

Read more...

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.

Read more...