just to be clear:
I use tags in less than 1% of the components that I write – in most
cases it’s just that one component that does the rendering.
that doesn’t mean, however, that it is not an important feature of the
language.
the bottom line, as far as I’m concerned, is that “tag islands” in
script would be a great feature.On 2/12/2015 5:49 PM, Igal @ Lucee.org wrote:
Option 2)
Don’t have a UIRenderer component but have tag-based custom tags for rendering your widget (lists) or pagination etc. THAT is what tag-based custom tags are really good at and useful for. Then on your page it’d actually uses the custom tags which probably fits nicely into whatever layout templating or page wrapper setup you prefer.Personally, I think option 2 is much to be preferred as it separates rendering (tag based in custom tags or templates) from business logic (script based in components) very nicely.
right. that’s the way I used to do it before components were introduced
into the language. but
it proved to be much slower to begin with.
by using functions I can use cachedWithin, so for example, if I pass
a widgetId and the function has to do a lookup to get more details (like
name, price, etc), this can all be cached by Lucee internally, which
makes it even more performant.it keeps all of my rendering code in a single file, so it’s much
easier to find the piece I’m looking for when I need to do so.On 2/12/2015 5:39 PM, Kai Koenig wrote:
- the main difference between you (plural) and I is that you try to push me to do things your way, while I prefer to keep my options open
I would strongly debate that, but that’s a different discussion.
- Kai – the fact that you don’t understand something doesn’t make it bullsht. I’ve always treated you with respect – it’d be nice if you’d try to do the same
Just to make things clear - the bullisht comment was not targeting you in particular but anyone in this discussion trying to convince me of breaking away from common-sense separation of concerns architectural principles without providing a use case why their proposed solution is better.Now you HAVE supplied such a case (see below) and we can discuss your argument. That has nothing to do with not understanding something at all.
- I will try to show an example of what I mean, hopefully the oversimplification will not make it miss the point
a) I don’t see how the approach below differs from what Abram’s said:"So, what would stop you from just including a cfm file with your UI stuff if you want it inside a cfc? To me that is the cleaner approach.”
To me, that’d be a much clearer approach, too, instead of sticking markup into a component. If you really wanted to have a UIRenderer component.
b) Let’s assume you did NOT have tags in components, how would this requirement be solved nicely?
Option 1)
Script component including a tag/markup file. That’s essentially the CFML-based version of a mixin (well, -ish) and I don’t think there’s anything wrong with that.Option 2)
Don’t have a UIRenderer component but have tag-based custom tags for rendering your widget (lists) or pagination etc. THAT is what tag-based custom tags are really good at and useful for. Then on your page it’d actually uses the custom tags which probably fits nicely into whatever layout templating or page wrapper setup you prefer.Personally, I think option 2 is much to be preferred as it separates rendering (tag based in custom tags or templates) from business logic (script based in components) very nicely.
Cheers
Kai
