cfimport with empty prefix
Pete Oliver-Krueger
issue, and found this post from a few months ago.
Actually, ACF does not require that one have an implementation for
every tag in the namespace. (At least it doesn't with CF7 and CF8.)
If there is not a custom tag template for it, it will ignore and just
output the tag.
This is a really useful feature of ACF, when working with WYSIWYG
editors and tag libraries that override HTML tags.
Any chance Railo can be updated to match ACF?
cheers,
pete
On May 27, 4:32 pm, Barney Boisvert <bboisv...@gmail.com> wrote:
> The behaviour is identical on Railo and ACF in this regard. If you
> import a namespace, you must have an implementation for every tag the
> CFML parser will encounter within that namespace.
>
> cheers,
> barneyb
>
> On Thu, May 27, 2010 at 1:18 PM, Hive <bac...@1a-infosysteme.de> wrote:
> > Hi everyone,
> > just read this article and gave it a try:
> >http://www.markdrew.co.uk/blog/post.cfm/overwriting-html-tags-using-c...
>
> > I've imported a tag-directory referenced by an application-mapping
> > using
> > <cfimportprefix="" taglib="/blog/com/base/form">
> > The next line was:
> > <h1>New Post</h1>
>
> > After doing so, Railo showed this message:
> > could not find template [h1.[cfm|cfc]] in the following directories [/
> > blog/com/base/form]
>
> > I thought the standard behaviour for Tags not found was to just put
> > them out?
Sean Corfield
<pe...@millionmunkeys.net> wrote:
> Actually, ACF does not require that one have an implementation for
> every tag in the namespace. (At least it doesn't with CF7 and CF8.)
> If there is not a custom tag template for it, it will ignore and just
> output the tag.
>
> This is a really useful feature of ACF, when working with WYSIWYG
> editors and tag libraries that override HTML tags.
>
> Any chance Railo can be updated to match ACF?
No.
I was a strong advocate for this behavior being added to ACF in the
first place and had to fight very hard to have it included - because
of objections on the grounds of performance, complexity and
counter-intuitive behavior. All very good arguments from a number of
parties both within Adobe and within the community.
I intended it to support DSLs - in the way that cfSpec uses it - where
*all* non-CF tags in a file were 'special'.
The reason I think Adobe's behavior is strange is because it's not
consistent with a named import:
<cfimport prefix="foo" .. />
<foo:what />
If what.cfm does not exist, you get a run time error.
<cfimport prefix="" .. />
<what />
I think that should behave the same way: no what.cfm => error.
The empty prefix should not lead to unique semantics.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
Pete Oliver-Krueger
upgrade my server my pages will start failing? The LiveDocs don't
mention such a change.
I certainly respect your opinion, because it is always well though-
out. I can see your point on performance impact, but here I would
actually disagree with you from the HTML/XML standpoint. The HTML
specs for browsers, at least, dictate that if an unrecognized tag is
encountered, it should just output the tag and ignore it. I would say
that that is the default behavior in the semantics, rather than an
entirely new set of semantics for the empty string. I would argue
that throwing the error when a prefix is present, but the template is
not, is against the original intent of the specs (or at least the
precursor specs for HTML that I found back when I originally was
researching HTML). A non-abortive warning to the log would be helpful
and appropriate, but I think a failure goes to far. (It would also
bring the semantics for with- and without-prefix back in line again.)
Thanks for the reply,
pete
On Oct 19, 8:04 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> On Tue, Oct 19, 2010 at 3:11 PM, Pete Oliver-Krueger
>
> An Architect's View --http://corfield.org/
Sean Corfield
<pe...@millionmunkeys.net> wrote:
> So is this something that changed with ACF9, such that if I were to
> upgrade my server my pages will start failing?
What?
I didn't say anything about ACF9.
Please re-read my post.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
Michael Offner
template getting cfml tags and like for every cfml tag the rule is
very simple, when a tag does not exist a exception is throwed, this
has nothing to do with HTML rules.
That the result written to the response stream can be interpreted as
HTML by a certain client has nothing to do with this.
/micha
2010/10/20, Pete Oliver-Krueger <pe...@millionmunkeys.net>:
Mark Drew
Also, For example, in Railo archives you might want to include an image which you can't do at the moment. You could solve this really easily:
<cfimport taglib="htmltags" prefix="" />
<img src="someimage.png" />
You then have a img.cfm that turns the image into a binary into the html page itself, so it gets displayed.
Ok, that is one use case, but I have also used it for form field replacement, <a href=""> url parsing etc. It IS a handy method
Just my 2 Russian Copecks.
MD
Mark Drew
Railo Technologies UK
Professional Open Source
skype: mark_railo
email: ma...@getrailo.com
gtalk: ma...@getrailo.com
tel: +44 7971 85 22 96
web: http://www.getrailo.com
Michael Offner
Sean Corfield
> i have think about a additional attribute for the tag cfimport
> <cfimport taglib="htmltags" prefix="" ignoreNotExistingTags="true"/>
> naming of the attribute still open for discussion
ignoreNonExistentTags=
But if you're going to implement this you might as well make true the
default and have compatibility with ACF. Just with the caveat that it
will be slower than ignoreNonExistentTags="false" (right?).
Sean Corfield
ignoreMissingTags=
would be even clearer.
Michael Offner
empty. But in most cases the prefix is not empty and false is the
right value for compatibilty. Right?
/micha
2010/10/22, Sean Corfield <seanco...@gmail.com>:
Sean Corfield
> When true is the default we only have compatibility when prefix is
> empty. But in most cases the prefix is not empty and false is the
> right value for compatibilty. Right?
Ugh! Yeah, you're right. ACF throws an exception if a tag is missing
for a non-empty prefix (which is the right *default* behavior).
Perhaps the default for ignoreMissingTags= should be true if prefix=""
and false if prefix= non-empty? That would be ACF-compatible and still
provide control over the behavior.
Michael Offner
;-) pherhaps we simply should follow acf in this case, I think we have
nothing to loose. We can do it like you say, the attribute
ignoremissingtags take 3 different possible values.
- yes/true
- no/false
- auto (default)
I don't like it when the default behavior not can be set like for
cffunction-output
/micha
2010/10/22, Sean Corfield <seanco...@gmail.com>:
Mark Drew
I demand you add this attribute!!
That would be awesome!
MD
Sent from my iPhone