Can't apply custom meta to script functions with @ syntax?

[Mark Mandel]

So I ran into this today:

If I have the following:

/**

 * test update

 *

 * @mxunit:expectedException coldspring.orm.hibernate.exception.StrictTransactionException

 */

 public void function testFailUpdate()

 {

 }

Then the "mxunit:expectedException" meta data does not show up in the getMetaData() call on this object.

I wanted to bring this up here, in case (for some crazy reason) you guys decided not to implement this functionality?

I know it's controversial, but please tell me this was just some simple omission by mistake? Otherwise, you can't use mxunit:expectedException in your mxUnit tests, if they are script based.

Mark

--
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast

http://www.2ddu.com/

[Matt Quackenbush]

Railo does not (and will not) support comments affecting behavior. In other words, no comments (yeah, I know it's actually JavaDoc spec) to define attributes. There are a good many thread on the topic if you'd like some fun reading. :-)

[Mark Mandel]

Okay.

Looks like I can use expectedException="coldspring.orm.hibernate.exception.StrictTransactionException" at the annotation, which won't blow up on CF9.

Mark

[Mark Mandel]

* sigh *

Yeah this sucks.

On the ORM SessionWrapper in ColdSpring 2, there are annotation hooks (orm:persist) on methods that interaction with the DB (delete, save, merge, etc). This sets up a nice hook for AOP to be applied to.

This really super sucks for framework authors who are trying to support multiple engines, as a lot of frameworks are using the ':' delimiter in annotations, and the only way to do with in CF9 is through comments, otherwise it throws a compiler error.

I get the academic reasons, but pragmatically, I have to say - I think this is a bad decision.

Mark

[Gert Franz]

I see your point, but can’t you just pass in an additional argument to the method since then it shows up in the metadata as well?

We had a long discussion about supporting annotations in Railo or not. Some reasons why not:

-          They make the compilation process slower for 99.9% of the cases

-          Comments are stripped out by the compiler prior to the compilation process (this would need to change as well)

-          Comments affect code at runtime

-          You could use additional arguments/attributes to get additional metadata…

 

Those were the main reasons not to support it. I would appreciate any different point of view.

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies      Professional Open Source

skype: gert.franz         ge...@getrailo.com

+41 76 5680 231           www.getrailo.com

[Gert Franz]

Hey Mark,

 

I did some testing and found the following:

 

<cfdump var="#GetMetaData(testFailUpdate)#">

<cfdump var="#GetMetaData(testFailUpdate2)#">

<cfdump var="#GetMetaData(testFailUpdate3)#">

 

<cfscript>

 

/**

* test update

*

* @mxunit:expectedException coldspring.orm.hibernate.exception.StrictTransactionException

*/

public void function testFailUpdate()

{

}

 

public void function testFailUpdate2() mxunit:expectedException="coldspring.orm.hibernate.exception.StrictTransactionException"

{

}

 

</cfscript>

 

<cffunction name="testFailUpdate3" mxunit:expectedException="coldspring.orm.hibernate.exception.StrictTransactionException">

</cffunction>

 

testFailUpdate() works in CF and shows proper metadata, not in Railo

testfailUpdate1() works in Railo and shows proper metadata, throws a compiler error in CF

testfailUpdate2() works in Railo and CF and shows proper metadata

 

Which I guess your tweet is about… So at the moment you are either stuck to tag notation or use the ugly notation:

 

public void function testFailUpdate2() mxunit_expectedException="coldspring.orm.hibernate.exception.StrictTransactionException"

{

}

 

Which works in ACF and Railo.

 

I will let you know if we revisit the annotations…

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies      Professional Open Source

skype: gert.franz         ge...@getrailo.com

+41 76 5680 231           www.getrailo.com

 

Von: ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von Mark Mandel
Gesendet: Montag, 12. Dezember 2011 08:48
An: ra...@googlegroups.com
Betreff: Re: [railo] Can't apply custom meta to script functions with @ syntax?

 

* sigh *

[Mark Mandel]

Yep, that exactly it.

I get your position, and knowing parsers, I understand why it would suck to have to go through comment code to affect the underlying AST. (Although depending on what parser framework you are using, it should be easy enough to shunt the comment code to it's own channel, and then parse it on the side, but I digress). If I could go back in time and dissuade the Adobe engineers from setting this standard, I would (I'm not personally a huge fan). Or if I could do the same thing and let CF9 parse annotations with ":" in them for cfscript, I would also do that.

So people who write for multiple engines now have to either:

a) provide multiple annotations, e.g. orm:persist (in comments), and orm_persist (on the function)

b) use tags, and not script to define their functions.

To be honest, I'm really not keen on rewriting a whole component from script->tags just for this (as I'm sure you're not keen on rewriting large chunks of your parser).

It's a sucky position all around. I'm thinking I'll just go option (a) for now, and if Railo users want to hook into this annotation for applying AOP, they can use orm_persist.

(Wondering is orm-persist will pass the CF9 parser, that's a little less ugly, I'll give that a shot too).

But I guess my final point is - why make life more difficult for those people who write frameworks (who I would expect are the 99% of the people who have to support multiple engines) to support Railo?

Mark

On Mon, Dec 12, 2011 at 8:36 PM, Gert Franz <ge...@getrailo.com> wrote:

public void function testFailUpdate2() mxunit:expectedException="coldspring.orm.hibernate.exception.StrictTransactionException"

{

}

[Todd Rafferty]

You make it sound like this is personal against all framework developers. It's not. It was a decision made before ORM was implemented that we were not supporting annotations. If something has the ability to slow down your engine... why would the Railo team even consider it? Remember the whole 'vendor' difference of the language committee? This is one of them. Nothing more.

On Mon, Dec 12, 2011 at 5:21 AM, Mark Mandel <mark....@gmail.com> wrote:

But I guess my final point is - why make life more difficult for those people who write frameworks (who I would expect are the 99% of the people who have to support multiple engines) to support Railo?

Mark

 

-- 

~Todd Rafferty
Volunteer Community Manager
Railo Server - Open Source
----

Get Railo: http://getrailo.org/
Write Documentation: http://wiki.getrailo.org/

Report Bugs: https://issues.jboss.org/browse/RAILO
Request Features: https://railo.uservoice.com/

[Mark Drew]

Mark

Maybe I have missed the actual context of this, but do you really care how the annotations are implemented?

What I mean is, if ColdSpring is just doing a getMetaData() it is up to the objects that are adding the annotations to do them specifically for the engine. From the ColdSpring side you are just looking for those attributes in the metadata? Not how they are added in there. Correct?

I could have of course missed your point. 

Looking at my little test that I did on the train, in both CF and Railo you would get a similar way to get to the item:

metadata.functions[x].['mxunit:expectedException']

And it would be up to me to either do 

/**

@mxunit:expectedException ElvisLivesForeverException

*/

function doSomething(){}

(and for the record I will go and say that annotations suck harder than Divine Brown, and are twice as ugly) 

or 

function doSomething() 

mxunit:expectedException="ElvisLivesForeverException"

{

}

Regards

Mark Drew

[Mark Mandel]

Nah, sorry - that's not my point at all. And sorry if it came off all accusatory, it wasn't my intention, so my apologies if that was the case.

It's not even to do with ORM.

It's more that I'm seeing more and more frameworks using this style of annotation - mxunit has it (and it has a fallback as well), as well, if I'm not mistaken so does coldbox for a few annotation it uses to provide specific hinting. Honestly it had never crossed my mind that Railo wouldn't support something like that - otherwise I would never have implemented something similar in CS2 - as I'd seen the example being made is other places.

I guess it's a small split between vendors - which kinda sucks when you have to support them all really.

I'm quite as annoyed at ACF as well, for not being able to parse a 

function foo() orm:persist() {}

As it would blow up the parser on their end (and I have on my todo list to enter a bug for that too on the ACF bugtracker). But that's not going to change, and if it did, it wouldn't be until the next version of CF. If they could do that, this would have become a non issue for me personally.

The only other major deviation from ACF I can think of, is that Railo makes is the passing of Array's by reference - but the Railo engine provides a workaround for that, so people can port code back and forth between engines. Here Railo is the only one who can really bridge the divide on this particular thing, and it doesn't sound like it's ever going to happen.

I guess at the end of the day, it's a relatively small thing to be getting my knickers in a twist over - it's an annotation style after all. I'll just come up with a different annotation that both engines can parse for this particular use case. It may not be as pretty, but that's not the end of the world. It will let my unit tests go green for these particular tests for Railo and ACF and all will be well again in the world.

And from now on, I won't write cfscript components to be used in code that needs to be supported on all engines, because I've learnt the hard way ;o)

So apologies to all for the long rant.

Mark

[Mark Drew]

Mark, 

As per my previous email, I think you will need to have  a couple of different tests, one for Railo and one for ACF (and maybe some tests for the "other" engine ;)) 

Within CS you can read the attributes that are set, and can mostly do it with annotations in CF and with attributes in Railo. 

Would you really do this?:

/**

@orm:persist() 

*/

(regardless that ACF accepts it…) I think we are getting to the point that you are in fact, writing code in comments… why not:

/**

@orm:sql("WHERE BOB = something and something is better than something and bla bla")

*/

This is the reason I think annotations stand around in street corners spreading VD's 

That is code, that does work, sure, it is only used by certain people but still! 

CFML has had for years a way for you to add metadata into functions, properties and components. 

Sorry if I keep going on about how fugly that is but it makes Susan Boyle look like Angelina Jolie in comparison. 

MD 

[Gert Franz]

Hey Mark,

 

No problem at all, you are helping us find bugs in corners of Railo that, well are used by framework creators so it is important for us to fix those bugs as well.

 

The only thing I can say there is that some things won’t change in Railo since it would be a major drawback for CFML in general if we would follow the implementation ACF did. Like passing arrays by reference vs. by value. Thing is that ACF is the only language that does that. And what I tend to do if I need to pass in an array by reference as well is to do:

 

function susi (arrayAsStruct:struct) {

            var aMyVal = arrayAsStruct.value;

…

}

 

susi( { value:[1,2,3,4] } );

 

Since ACF passes structs by reference and arrays not, I pass in a struct that contains an array which in that case would be passed by reference.

 

So thanks for all your help since not only ColdSpring2 will benefit of whatever we are fixing, but the other frameworks as well….

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies      Professional Open Source

skype: gert.franz         ge...@getrailo.com

+41 76 5680 231           www.getrailo.com

 

Von: ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von Mark Mandel
Gesendet: Montag, 12. Dezember 2011 13:27
An: ra...@googlegroups.com
Betreff: Re: [railo] Can't apply custom meta to script functions with @ syntax?

 

Nah, sorry - that's not my point at all. And sorry if it came off all accusatory, it wasn't my intention, so my apologies if that was the case.

[Michael Offner]

i could think about a half way solution, supporting annotation just for meta data.

this will work:

* @susi Susanne

this will be ignore or the compiler throws a exception.

* @output true

/micha

2011/12/12 Gert Franz <ge...@getrailo.com>

[br...@bradwood.com]

> If something has the ability to slow down your engine... why would the Railo team even consider it?

At the risk of saying something very obvious, I'll just quote Sean here: "Compatibility with Adobe is essentially a 'must' for Railo and OpenBD to ensure portability of code with the largest player..."

As a person whose foray into Railo consists mostly of porting existing code over, out-of-the-box compatibility is huge.

On a related note, I can definitely see how parsing comments is a performance concern on compilation, but how "big" is compilation from a performance perspective?  Assuming most people are using some level of trusted cache, my production servers only have to compile a file once and then cache it for the next month until I update the code again.  I honestly don't know the answer which is why I'm asking, but how big of a deal is parsing/compilation really once a server has "warmed" up?

Thanks!

~Brad

[Todd Rafferty]

This is a personal opinion and should not reflected as the opinion of the team:

Show me a how many people actually use annotation in their CFML code and I'll show you an even bigger pool of people that don't use it or don't even understand it. I understand your statement of Compatibility. I get it. However, that's like saying Railo doesn't support cfquery or something big that is necessary to the language. We're talking about annotation, what I would consider to be a small feature and IMO, was a bad feature to begin with. Why in the world would comments ever impact coding?![/personal opinion over]

Let it be known that the Railo Team has been discussing the issue.

[Matt Quackenbush]

+infinity :-)

[Robert Rawlins]

I agree Todd - looking at the features most people use and running with that is a strong approach. Accepting your can't please everyone is part of the game.

I'd go even further though, taking that argument beyond just these annotations - into all the 'fluffy' non-essential features that the platforms have, things like document generation/manipulation, charting, ajax etc etc

Pull all of that stuff out of the core leaving it lightweight and nimble, and maintain them as separate pluggable modules - if people genuinely want them then they can be enhanced and developed - if not they can fall dormant, either way, the core team aren't wasting their time on it.

I don't mind much either way if Railo is to support these annotations - the one hope I do have though is that they take a strong stance on the choice they make, and make it defined and clear-cut. I don't much like the half-solution of supporting some but not others.

The platform should have a strong opinion that confidently leads it's developers down a path of best practice, so that we can all enjoy consistency and continuity in our code.

That is the one thing I like most about the 'we don't support it and never will' stance.

Robert

p.s. I also disagree with the opinion that Railo need furiously and unrelentingly chase Adobe's tale which has been suggested by some.

This may be a goal that can never be fully or consistently reached.

Take CFML by the balls - give them a damn good squeeze and make it your own and innovate.

As a developer I'm not looking for a cheap alternative to ColdFusion - I'm looking for a fast, robust and exciting platform upon which to build applications. I know there are 1000s upon 1000s of PHP, Ruby, Python, JAVA, .NET and PERL developers the world over looking for the same thing.

The things that make Railo exciting aren't the things that it's copied from Adobe.

[br...@bradwood.com]

> Why in the world would comments ever impact coding?!

I've got to agree there.  I know it's a wide-spread practice, but it isn't something that really makes sense if I was to design a system without compatibility in mind.

~Brad

[Todd Rafferty]

The fact that Micha publicly stated that he'd be willing to meet halfway on this issue is positive and means he doesn't feel that it's a waste of time.

[Mark Mandel]

To be honest, that's all I ever cared about - was the meta data stuff for functions and arguments.

I assume you allow @param hint values in the /** **/ comments, don't you (I should test this out)? so you have to be parsing the comments to be applying them to functions and arguments anyway, right?

If not through @param.value, is there a way in Railo to do custom meta data against arguments?

Thanks for considering this - it's much appreciated.

Mark

On Tue, Dec 13, 2011 at 2:32 AM, Michael Offner <mic...@getrailo.com> wrote:

i could think about a half way solution, supporting annotation just for meta data.

this will work:

* @susi Susanne

this will be ignore or the compiler throws a exception.

* @output true

/micha

[Mark Mandel]

Okay, another total assumption on my part (you would think I would learn):

So If I have:

component

{

    /**

     * This is my hit for this function here!

     *

     */

    public void function testFailUpdate()

    {

    }

}

It *doesn't* pick up the hint for the function, you HAVE to use hint="" in your script based components.

In Railo then - how do you apply hint values to arguments in script functions? I mucked around a bit, and I couldn't find a way to do that at all, without throwing some funky parser errors.

This is less of an issue for me personally (I generate documentation for CS2 off my cf9 install), but for anyone who is using script style functions and wants to use any auto-document generating system, such as ColdDoc or the like, they will get no hints for their arguments, and no hints for their functions if they have used the comment style of hint annotation.

Mark

[Todd Rafferty]

This works just fine:

component{

public void function fooBar() hint="This is a test"{}

[Mark Mandel]

Todd - but what if you want to apply hints to argument parameters?

I can't do:

public void function fooBar(required string hint="this is awesome" awesome) hint="This is a test"{}

It just fails.

Is this not possible? or is there an alternate syntax?

My personal opinion is the /** */ comment block for hints is much nicer to look at for script based components - but that may be just me. Not huge issue for me personally though.

Mark

[Todd Rafferty]

I agree it's not working, open a ticket and Micha will either give you the proper syntax or fix it.

[Mark Mandel]

Thanks for listening to me on this.

I've implemented the following:

/**

     * Specifically updates a persistent object.

*

* @entity the entity to update

*

* @orm:persist true

     */

    public any function update(required any entity)     orm_persist="true"

    {

        //do stuff

    }

This way, if you're on Railo, you can hook into orm_persist, which works as well, and if you guys ever decide to support meta data and hints through comment code, then the ':' style of annotations will become available at that point as well.

Thanks!

Mark

[Mark Mandel]

Actually, I just had an epiphany, that makes me feel stupid because I didn't have it earlier.

Easy answer. Just rewrite the functions that cause the issue - you don't need to write the whole component.

Take the current component, wrap it in a <cfcomponent><cfscript> (original content) </cfscript></cfcomponent>

And then pull out the functions that have the orm:persist on them, and rewrite them as tag based functions.

Presto. Bob is now your uncle.

*facepalm*

Mark

[Mark Mandel]

Just to bring attention to them (I swear I will shut up soon), there are 2 bugs already in Jira that deal with the fact you can't do hints, or custom annotations on arguments in cfscript:

https://issues.jboss.org/browse/RAILO-1327

https://issues.jboss.org/browse/RAILO-958

For me personally, I'm not fussed if this is defined in comments or not - I'd just like the functionality to be there.

Mark

[Michael Offner]

we will look into it.

stay tuned ;-)

/micha

2011/12/13 Mark Mandel <mark....@gmail.com>