Component lookup via Custom Tag Path

[MrBuzzy]

Howdy,

 

I have noticed that unlike ACF, Railo does not lookup components via the CustomTag Paths.

 

This means only the mappings can be used to resolve components.

Using mappings for this purpose is limited because it does not (easily) allow for components to be located in more than one folder.

 

Using the CustomTag Paths approach in ACF, I can add several folders and they will all be used to find components.

I really like this approach and wish Railo supported it.

Doing it this way means it's possible to have a "mapping free" environment, or atleast mappings are used only where truely required (ie: /coldspring mapping).

 

Made up example below;

 

<!--- This component is located in E:\SharedComponents\biz\mrbuzzy\utils\ --->

<cfset cfc1 = createobject("component","org.mrbuzzy.utils.Blah")>

 

<!--- This component is located in E:\App1Components\biz\mrbuzzy\tool\ --->

<cfset cfc2 = createobject("component","org.mrbuzzy.tool.Blah")>

 

Note the 'package' (org.mrbuzzy) is actually spread accross multiple locations, like jar files can be, when defining a classpath.

 

The above code is not runnable on Railo, because I would be required to create TWO /org mappings (which is not possible?).

 

Also, I find the Custom Tag Path lookup approach encourages developers to develop in a more OO way using CFC's only, as they don't have mappings that can be expanded or used for includes.

 

Some people don't realise that ACF works like this, so I think Railo could name it better, say "Component Paths" or "Component Library" or whatever :)

 

What do you think?

 

Cheers.

 

[Gert Franz]

At the moment we are not supporting it. Several reasons:

 

1.      Bad practice. Since you don’t know for sure what component you end up with

2.      Performance. Railo needs to check the different directories and subdirectories

3.      Ambiguous references possible. Therefore bad practice.

 

Just imagine you open the windows explorer and type setup.exe and the first setup.exe it finds will be executed…

 

This was the bad stuff… now things you can do:

You can define a mapping called

org.mrbuzzy.utils that points to E:\SharedComponents\biz\mrbuzzy\utils\

and one called

org.mrbuzzy.tool that points to E:\App1Components\biz\mrbuzzy\tool\

 

so combined mappings are possible in Railo.

 

And we will add the same functionality for cfc paths as it already exists for custom tags. But we won’t use the custom tag paths additionally as search resources. If you need them to be searched, just will need to add a cfc path to the Railo admin once we have implemented it.

 

Hope this helps. Would you agree?

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies       Professional Open Source

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

+41 76 5680 231               www.getrailo.com

--

You received this message because you are subscribed to the Google Groups "Railo" group.
To post to this group, send email to ra...@googlegroups.com.
To unsubscribe from this group, send email to railo+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/railo?hl=en.

[Sean Corfield]

On Thu, Nov 26, 2009 at 8:42 PM, MrBuzzy <mrb...@gmail.com> wrote:
> I have noticed that unlike ACF, Railo does not lookup components via the
> CustomTag Paths.

...

> Using the CustomTag Paths approach in ACF, I can add several folders and
> they will all be used to find components.

I started down that path when I was back at Macromedia and we quickly
abandoned it - putting application code inside the CF install tree
makes deployments more complicated and can leave you open to some
unexpected CFC discoveries, as Gert hinted - and the performance hit
was very noticeable as well.

I'd strongly suggest using per-application mappings (in
Application.cfc) so you have more control over search paths and so
that you don't need mappings in the administrator.

If you really have a set of common CFCs you want every web application
to use, you can always create a mapping in the Server Administrator...
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[MrBuzzy]

Hi Gert, yes I think the 'CFC paths' approach would be a good one.
It would help and no, I don't expect the custom tag paths to be searched for CFC's or vica versa. Your solution sounds perfectly suitable.

Maybe you will consider giving the 'CFC paths' a configurable order of precedence too...

I can't not reply to your points below, but I come in peace!

1.      Bad practice. Since you don’t know for sure what component you end up with

I understand the point, but BAD? Or just not the best...
If I use package "org.mrbuzzy.busnessx.whatever" that's pretty well name spaced. Clashes would be rare and can be picked up in integration testing if not earlier.

2.      Performance. Railo needs to check the different directories and subdirectories

I understand. I'm not sure it's as bad as you think. (and I thought these mechanisms were fairly well cached and even more configurable in Railo!)

When the CFC's are looked up, there's no reed to recurse directories like CustomTags lookups do. The package reflects the directory structure and the CFC is found.

Surely looking up the CFC's this way is the same as having a mapping with no name? (Like the webroot).
Or instead - adding multiple mappings to represent the children of a particular folder, the preformance is relative to the number of mappings and not necesarrily better or worse. But comes with extra maintenance.

I thought it was only CustomTag lookups that got recursive and funky allowing <cf_example> to be burried way down in any old folder and easily occluded by another folder.

3.      Ambiguous references possible. Therefore bad practice.

Yeah, but if you use package names it's all good. Don't 'practice' creating components without packages. Encourage CFC's to not be created in the 'root' of the new CFC paths or webroot.

Perhaps the lookup gets ambigous but this can already occur with mappings and web server mappings and custom tags too. It all still 'works'.

Just imagine you open the windows explorer and type setup.exe and the first setup.exe it finds will be executed…

Yep it's funky. But it can happen!
If you (or someone before you) had deemed it important to set the PATH then it will indeed run the first setup.exe it finds. This may have been by design, good, bad, whatever but it's do-able.  

And we will add the same functionality for cfc paths as it already exists for custom tags. But we won’t use the custom tag paths additionally as search resources. If you need them to be searched, just will need to add a cfc path to the Railo admin once we have implemented it.

Hope this helps. Would you agree?

Yep, I agree 'CFC paths' would be nice. Nameless ones though, not like mappings ;)
 
Thanks so much for hearing me out.

Greetings from Switzerland

Gert Franz

 Greetings from Australia

[Mark Drew]

Hmm, just as a comment on obviousness, err, a custom path is for custom tags yes? if you can call components from there sounds like a bit of on error non? I mean you *CAN* do it... but that sounds like something out of spec of the engine. 

Maybe component paths are better but that is what mappings are for... or maybe they should just be for file includes? or... get this... removing custom tag mappings and use mappings! 

I don't know but it sounds like that working is not the most elegant solution to something.

MD

--

You received this message because you are subscribed to the Google Groups "Railo" group.
To post to this group, send email to ra...@googlegroups.com.
To unsubscribe from this group, send email to railo+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/railo?hl=en.

Mark Drew

Railo Technologies UK

Professional Open Source

skype: mark_railo

ma...@getrailo.com

+44 7971 85  22 96

www.getrailo.com

[MrBuzzy]

Unfortunately I don't have any idea what the spec of the engine is.
It is a documented feature. And it's not my fault Adobe called it "Custom Tag Path" if I only use it to look up components.

See: http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec22c24-7e17.html

It's been working for me, well, for quite some time in ACF and I'm raising it because I noticed it. I thought it might be helpful and I didn't expect this to turn in to "youre doing it wrong".

I had to merge a couple of component folders AND create a /com /org and /net mapping to get the equivalent functionality on Railo.

Maybe the world's gone mapping crazy ,you don't always need them...
What about java? it doesn't need mappings, just a classpath of packages that come from multiple sources. And when you add packages in to your java build path you choose the location but you don't give it a name.
In CF mappings are fine if you only want to point to one location, with a single word, ie: /transfer /coldspring /config /tags/ver1, etc.

[Michael Offner-Streit]

just my 5c

for custom tags you can define multiple directories, where your custom tag are located, then you can define that railo search custom tags in the current location too
and finally you can define that railo search recursivly for custom tags inside the custom tag directories.

what we plan for one of the next releases:
- you can enable or disable that railo search for a cfc from the current location (like now enabled by default), this works already in backend, only the switch in admin frondend is missed.
- you can enable or disable that railo search inside the webroot/mappings for cfcs.
- you can define as many directories you want, where railo search for cfcs.

what we not plan to support
- railo search for cfcs recurivly inside the cfc directories.

then you can define the same directories for cfc path and custom tag path, if you like that, the the only diffrerents to ACF will be, that we not search recurivly for cfcs.

/micha

-- 
Michael Offner-Streit
CTO
Railo Technologies GmbH
michael...@railo.ch
www.getrailo.com

Mailing List (english): http://groups.yahoo.com/group/railo_talk/
Mailing List  (german): http://de.groups.yahoo.com/group/railo/
Linked in: http://www.linkedin.com/e/gis/71368/0CF7D323BBC1
Issue Tracker: http://jira.jboss.org/jira/browse/RAILO
Blog: http://www.railo-technologies.com/blog

MrBuzzy schrieb:

[MrBuzzy]

Thanks Michael. Are you sure ACF searches recursively for CFC's?

(I'm not aware of that and it's not what I'm requesting, so am fine
that railo won't support it.)

>>> <mailto:ra...@googlegroups.com>.

>>> To unsubscribe from this group, send email to
>>> railo+un...@googlegroups.com

>>> <mailto:railo+un...@googlegroups.com>.

>>> For more options, visit this group at
>>> http://groups.google.com/group/railo?hl=en.
>>
>> Mark Drew
>> Railo Technologies UK
>> Professional Open Source
>> skype: mark_railo

>> ma...@getrailo.com <mailto:ma...@getrailo.com>

>> +44 7971 85 22 96

>> www.getrailo.com <http://www.getrailo.com>

>>
>>
>>
>> --
>>
>> You received this message because you are subscribed to the Google
>> Groups "Railo" group.
>> To post to this group, send email to ra...@googlegroups.com

>> <mailto:ra...@googlegroups.com>.

>> To unsubscribe from this group, send email to
>> railo+un...@googlegroups.com

>> <mailto:railo%2Bunsu...@googlegroups.com>.

>> For more options, visit this group at
>> http://groups.google.com/group/railo?hl=en.
>>
>>
>> --
>>
>> You received this message because you are subscribed to the Google
>> Groups "Railo" group.
>> To post to this group, send email to ra...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> railo+un...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/railo?hl=en.
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Railo" group.
> To post to this group, send email to ra...@googlegroups.com.
> To unsubscribe from this group, send email to
> railo+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/railo?hl=en.
>
>
>

--

Sent from my mobile device

[Paul Klinkenberg]

Hi Michael,

So if I understand you correctly, you will allow people to call createObject("component", "mycfc"), where mycfc.cfc is located in the root of a custom tag path, BUT createObject("component", "directoryname.mycfc") won't work, even though mycfc.cfc is inside the directory 'directoryname' in the root of a custom tag path?

If that's what you are planning to do, then imo you're missing the complete point what people are trying to have fixed.

I know of at least 2 larger cfml companies (Gert has been to one of them btw) who just have one or two 'library' directories with most of their cfc's, added as a custom tag path, which are used in almost all web apps:

  .

  -- org.camden.blabla

  -- com.whatever.bla

  -- ownextension.abc

  -- etc. for another 30 dirs

I understand you constantly try to guard the speed of Railo, but do not forget that these options are already available in ACF 7, 8, and 9, (6 even?), and lots of people are using this!

Just add it to the mix, make it an option, it will take away one of the last bumps so a lot of new people can start using Railo.

I even received a mail from a lead technical developer a while ago who said this WAS the last thing that has to be fixed before they can start using it... If you understand Dutch, I can forward it to you ;-)

Regards, and thanks for the explanations,

Paul Klinkenberg

[Gert Franz]

Well no… we will implement it I guess by having the startpoint for the search defined in the admin.

 

Let’s assume you will add the cfc search paths:

E:\myCFCs

D:\customCFCs

and you address a CFC like this

createObject("component", "directoryname.mycfc")

Railo will expect the cfc named mycfc.cfc to be either located in

E:\myCFCs\directoryname

or in

D:\customCFCs\directoryname

in order for it to be found. I guess that would solve exactly the problem you are addressing… Right?

 

Gert

[Paul Klinkenberg]

Hi Gert,

Yes, that would solve it!

Then I don't understand the fuss about the 'not recursive' part, but hey, as long as the problem will be solved, who cares ;-)

Cool!

Paul Klinkenberg

[Michael Offner-Streit]

custom tags are searched also in every sub directory, when you call for example <cf_susi>, railo search "susi" not only inside the custom tag directory, it search also in every folder inside the custom tag directory.
but when you have this createObject("component", "susi") railo will not search in every sub folder for susi and when you are defining
createObject("component", "directoryname.mycfc") railo search inside {custom-tag}/directoryname/, but not inside the subfolder of directoryname.

/micha





Paul Klinkenberg schrieb:

[Paul Klinkenberg]

Hi Micha,

Thanx for the clarification. I don't think anyone would have expected Railo to work this way anyway, so very good to keep it out.

Paul Klinkenberg