I actually like tags in script

188 views
Skip to first unread message

Rory

unread,
Sep 5, 2014, 12:34:40 AM9/5/14
to ra...@googlegroups.com
I want to discuss one item of the cfscript improvement conversations happening recently that I disagree with. I think most agree that Adobe's cfscript tag implementation in CF11 is unnecessarily confusing:

cftag(attr=1, attr2=2) { ... }

Adam gives his opinion that tags requiring a body could be implemented as functions that accept a closure:

tag(attr=1, attr2=2, function(){
...
});

Some related posts: 

I am of the opinion however that I like the Railo implementation of tags:

tag attr=1 attr2=2 {
 ...
}

These are my reasons for liking Railo's implementation: 

1) We already have CFML <cf> tags and for better or worse they are here to stay. Railo's implementation requires just dropping of the "cf" and this keeps the language consistent from both ends.

2) Tags with bodies mean that there is an expectation of executing a code block which also implies block nesting. I think function passing for the purposes of creating code blocks is actually a relatively ugly style and Railo has a unique advantage. Take this comparison for example: 

tag(function(){
     anotherTag(function(){

     });
})

VS

tag {
    anotherTag {

    }
}

Further then, why should 'native' code blocks only exist for traditional blocks of if/switch/try/else? If function-block style is superior, why not design a language that looks like this? 

if(1<3,function(){

   try(function(){

   }, catch=function(){

   })

})

The reason we wouldn't like that is because of historical momentum for what we are used to, it would be unnecessary boilerplate for the common case, and it would also look like shit. 

So I'm asking, why pepper the code with extra "function()" syntax to achieve the same thing we already have today? I think the Railo version is much cleaner. In fact, I want Railo to double down and make CFML custom tags work fully in cfscript syntax as above so that we can do more natural DSLs in script. Take for example the testBox callbacks:

function run(){
          describe("A Spec", function(){

               beforeEach( function( currentSpec ){
                    // before each spec in this suite
               });

               afterEach( function( currentSpec ){
                    // after each spec in this suite
               });
          });
});

Instead of that callback soup, I'd love to be able to implement something clean with custom tags in cfscript:

function run(){

    describe title="A Spec" {

  beforeEach {
// before each spec in this suite
  }

  afterEach {
// after each spec in this suite
  }
    }
}

3) If the reason for moving to callbacks is to be more 'mainstream', I don't think that will win any hearts. Anyone who wants this style might as well jump ship now. 

I instead want Railo to be an easy to learn, batteries included, high performance JVM web application platform. That is its only market potential. Railo/CFML will never catch up to any of the other mainstream languages. The declarative syntax, BIF library (as opposed to traditional OO package import), built in services (ORM, Rest, S3, Caching, Search), parity between script and tags all come together to make a complete and flexible package. In fact I would like Railo to update and increase its function library and core services further to make it even easier for modern applications.

I agree with the fact that some tags simply don't translate well (cfparam, cfquery) but so what? At least the current implementation is mostly straight forward, and really only screwed up by ACF. I also agree that in general no new self closing tags should be added to the language, and instead that functionality should only be added as functions going forward. But any tag which fits a nested execution block style, well why the hell not keep doing it the Railo way?

There are use cases for features implemented as native bock style, regular BIFs, or function passing/callback style. Use the best method for the job. I like that Railo has all three and I really don't see the problem, what am I missing?

Rory

Dominic Watson

unread,
Sep 5, 2014, 4:01:47 AM9/5/14
to ra...@googlegroups.com
I agree. The only thing that makes me *almost* disagree is the factor of attracting new developers to the language. It *does* sometimes feel a little messy to have some things implemented in this tag style syntax while other things are implemented as functions.

But I think with your great example of testbox test suites done in "tags", the expressiveness of the language really comes through and should be a celebrated difference rather than something to shy away from just because other languages work in another way.

Dominic

Dominic Watson

unread,
Sep 5, 2014, 4:59:20 AM9/5/14
to ra...@googlegroups.com
The only other exception I think is where those tags could be written as one line functions (there are plenty of them). i.e. where the tag does not support nesting:

result = dbinfo(...);



On Friday, 5 September 2014 05:34:40 UTC+1, Rory wrote:

Michael Offner

unread,
Sep 6, 2014, 3:41:52 PM9/6/14
to ra...@googlegroups.com
My most loved tag in cfscript today is "loop", in my case "loop" has completely replaced "for" for nearly all cases. In my opinion loop is easier to write with less noise around it.
So we will for sure not remove script tags and we will also add support for custom tags in the future.
Micha
--
Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/railo/ad4b9f82-e460-456f-a0f5-2a717182fad0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
/micha

Michael Offner CTO Railo Technologies GmbH

Igal @ getRailo.org

unread,
Sep 9, 2014, 4:04:32 PM9/9/14
to ra...@googlegroups.com
my favorite is also loop, but in only in the case of Arrays and Structs (which for whatever weird reason are referred to as Collections), because in Railo we can use the index and item together.

loop collection=someStruct index="key" item="val" {

  // now you have access to the value without a hashtable lookup, yay!
}

I propose that we add the alias STRUCT to COLLECTION, the alias KEY to INDEX, and the alias VALUE to ITEM.

For more options, visit https://groups.google.com/d/optout.

-- 
Igal Sapir
Railo Core Developer
http://getRailo.org/

Peter Boughton

unread,
Sep 9, 2014, 5:45:17 PM9/9/14
to ra...@googlegroups.com
 > I propose that we add the alias STRUCT to COLLECTION,
 > the alias KEY to INDEX, and the alias VALUE to ITEM.
 
I thought key and value were already aliased, but it looks like that bit never got implemented.

They definitely should be - would then be consistent with the terms used for the Struct functions/methods.

Michael Offner

unread,
Sep 10, 2014, 2:29:01 AM9/10/14
to ra...@googlegroups.com
Railo is already supporting "struct", but "struct" is not a alias to "collection" then "collection" (in Railo) is not limited to structs, collection can be a array, a query, ..., so every type of collection (see interface collection:http://www.getrailo.org/javadoc/railo/runtime/type/Collection.html).

when we added support for "index" AND "item" in every context of the tag, we also discussed about adding alias as well, but we decided against it, because it seemed to be confusing having index,key,item and value as attributes.
But now Railo is supporting alias for tag attributes as well, so i added "key" and "value" just yet.

Micha



For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages