Dan
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/99798043-B60D-4DF7-A327-94F64A9598A3%40web-meister.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKfy9p%3DKz8g1Fed0fvyqVLLiDBRZ7aPcB52zZ1BttEn_qg%40mail.gmail.com.
On Feb 6, 2015, at 1:28 PM, Jonas Hauß <hauss...@gmail.com> wrote:
How about Mustache.js in Lucee?
Simple syntax and very easy to use!
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/3906b56f-bf31-4e1b-91f8-19e219a870c3%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CC2A1C6D-6C64-439D-B8B1-24D88CC44A73%40web-meister.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/541A189C-9B57-4B51-BFAD-ED71490F966E%40gmail.com.
For instance, if we make the templating syntax the same as handlebars or mustache or all the other double-curly template engines, it further blurs the line between what is server side and what is client side and could easily cause collisions. Many times I want to serve a fully server-side rendered page that has client-side templating embedded in the html so that it can dynamically re-render when state changes client-side. If Lucee automatically parsed the double curlies it could bring unexpected results like throwing server side errors.
my $0.02
I personally think the templating syntax for cfml is actually really good if used responsibly. Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.
On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <cfxc...@gmail.com> wrote:I agree, I do not see a need for change here. CFML is really good for view templates.I personally think the templating syntax for cfml is actually really good if used responsibly. Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/81cfeb20-523d-48cc-bab4-8c3be123cd00%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/DD6264EC-BAD7-4032-ADEA-DDBCBA1FF470%40corfield.org.
On Sat, Feb 7, 2015 at 8:53 PM, Sean Corfield <se...@corfield.org> wrote:I also agree but I would like to see the _amount_ of logic restricted in view templates so perhaps a <lc:tagname …> … </lc:tagname> syntax but with only a small subset of tags actually available? Maybe just:* <lc:if>* <lc:switch>* <lc:loop>
* <lc:script> - if you really must embed logic, at least make it script!
And the ability to call built-in and user defined functions as well ?
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKeWA-4D0STM1-W3GURNj4%2Bm8FUv5HcJ8-n%2BW3pSreV5%3DA%40mail.gmail.com.
On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <cfxc...@gmail.com> wrote:I personally think the templating syntax for cfml is actually really good if used responsibly. Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.
I agree, I do not see a need for change here. CFML is really good for view templates.
I agree on the moving from CF stigmas, but I think we should be careful on what we throw out with the dishwater.
For instance, if we make the templating syntax the same as handlebars or mustache or all the other double-curly template engines, it further blurs the line between what is server side and what is client side and could easily cause collisions. Many times I want to serve a fully server-side rendered page that has client-side templating embedded in the html so that it can dynamically re-render when state changes client-side. If Lucee automatically parsed the double curlies it could bring unexpected results like throwing server side errors.
I personally think the templating syntax for cfml is actually really good if used responsibly. Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.
2 things are very important for me:1. it should be about loosing weight not get a other person, we should keep what makes cf unique and good, only ditch the bullshit.2. The application.cfc is like a mini framework and I was asking myself a lot in the past, should we go further with that concept. But I don't think so today, we have great framworks like fw/1 and coldbox that do a great job in that sector, so add any further framework logic to the language only limits the possibilities.Micha
I don't mean to be overly dramatic, but is it really our intent to do away with open source CFML? To improve on every existing language, more or less from scratch?
> I'd say custom tag for that. Or just not allow it, because if you needed it, you're doing it wrong. Don't do it wrong.thats just like, your opinion man.
And I think its important to point this out because there are some people who take what you say as having weight and authority here.
Please remember that there are people who need to write simple scripts, not applications - and that may mean a one page chunk of logic and view. Please, in general, remember that there are people who have needs and tastes that don't match your own.
I'm not against supporting other template engines, especially if it makes someone coming from other languages more comfortable, but I don't see any point in getting rid of pound signs and cfml just because you think its old and crufty.
Give people options, don't restrict based on some high-horse idea of right and wrong. Lets extend the language, give new options. Make the case why the new way is the best way and let developers convert as they are convinced, not take away their toys and tell them they're playing with them wrong.
I would still argue [...]
I'd like to also propose that for large feature proposals like this that we take a page from JS, Python, Java and other languages and actually put forward actual formal proposals. Here is an example from python: https://www.python.org/dev/peps/pep-0255/, or another from JS: https://github.com/tc39/Array.prototype.includes/ This would allow us to discuss and refine ideas, allow the lucee team to accept proposals but say that certain parts need tweeks or more thought. It would also make it clear to outsiders exactly what status a given proposal is in, and if it has the approval of the team or not. I would argue both the google group and the bitbucket issues are not ideal places for conversations like these, unless it is a simple new function or tweak. I don't know all the answers on how to do it, but want to throw it out there for considerations.
My 2 cents.
> Stop diluting the merits of your contribution. Even if I don't agree with it ;-)I understand that my statements may be contentious and intend to present them with humility. Its up to you to decide their merits.
Well I think that's your interpretation of what it means. I agree its an unnecessary ending but when I have added it I mean 'my thoughts for what they're worth'
A
Sent from my phone
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKctmrsqC%2Bkm%2BG7DPaYsN53317nCj--vc_DqzFK_iraxMg%40mail.gmail.com.
Appending "my 2 cents" / "my 2p" / etc is the humility equivalent of saying "you're a prick" and then appending a smiley face to it so you can say "but it was a joke" if called out on it.
Well I think that's your interpretation of what it means. I agree its an unnecessary ending but when I have added it I mean 'my thoughts for what they're worth'
On 8 Feb 2015, at 16:25, Ryan Guill <ryan...@gmail.com> wrote:I wonder how express.js handles this? I did some cursory googling but couldn't find anything.
this .lucee stuff is in addition to the existing and continued CFML support
On 9 February 2015 at 01:20, Adam Cameron <dac...@gmail.com> wrote:this .lucee stuff is in addition to the existing and continued CFML support
On that point, the discussion seems to have been along the lines of "here's all the ruby features we want to pull in to lucee."
I'm going to re-ask the earlier question. "What's the case for it vs the tons of already mature server-side languages?”
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/D27145D7-D7EA-4B0F-B089-91A13A6AF448%40gmail.com.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKdtP7zoKP1YCs3ik1iioGLoB0RZzd%3D2Eso_FC50ba5nNQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2A49BB73-4921-431A-9A83-74D630F08DED%40web-meister.com.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/f5d7b045-fa86-41d3-8ba8-bd791189f409%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEByT8tuA%3D%2BszzffHn_vv7vhiA7Gu3zEa4hRV%2Bpap8G1DjQ%40mail.gmail.com.
I like this list as well, with <lc:if> being crucial. One of the biggest issues I have with Handlebars, and I love Handlebars, is that there is *zero* logic allowed, which is good in theory, but in practice, can be a pain the in the rear. Handlesbars has an IF, but only for one value, you can't do something like, if X=Y.When migrating a CF site to Node recently and using Handlebars, I had to write a custom function just to support this in CFML:<option value="something" <cfif rc.category is "something">selected</cfif>>Something</option>
On Saturday, February 7, 2015 at 1:53:09 PM UTC-6, Sean Corfield wrote:On Feb 7, 2015, at 11:37 AM, Jean Moniatte <je...@ugal.com> wrote:
On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <cfxc...@gmail.com> wrote:I personally think the templating syntax for cfml is actually really good if used responsibly. Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.
I agree, I do not see a need for change here. CFML is really good for view templates.
I also agree but I would like to see the _amount_ of logic restricted in view templates so perhaps a <lc:tagname …> … </lc:tagname> syntax but with only a small subset of tags actually available? Maybe just:* <lc:if>* <lc:switch>* <lc:loop>
People still will migrate existing apps, so compatibility is relevant to a certain point.Micha
On Feb 7, 2015, at 11:37 AM, Jean Moniatte <je...@ugal.com> wrote:On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <cfxc...@gmail.com> wrote:I agree, I do not see a need for change here. CFML is really good for view templates.I personally think the templating syntax for cfml is actually really good if used responsibly. Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.I also agree but I would like to see the _amount_ of logic restricted in view templates so perhaps a <lc:tagname …> … </lc:tagname> syntax but with only a small subset of tags actually available? Maybe just:* <lc:if>* <lc:switch>* <lc:loop>* <lc:script> - if you really must embed logic, at least make it script!
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
For instance, please don't require that components be script based
For instance, please don't require that components be script basedI would be very strongly against allowing Lucee components to be written using tags. But of course you would be able to continue to write .cfc files using tags, if you like that approach.
On Thursday, February 12, 2015 at 2:57:22 PM UTC-5, Sean Corfield wrote:
One of the big problems that plagues CFML code is the mixing of logic and display code -- precisely because it's always been so easy to write logic in tags and therefore in amongst the HTML. Having the language really help you here by "strongly encouraging" a strict separation of logic from display code -- via script-for-logic and tags-for-display-code -- will produce better, more maintainable code, that is far more approachable to non-CFML developers.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2019b5ab-9d80-4184-9890-f6e52e14fd02%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/823A79B3-22BB-4FF3-B4EA-CBBC68C39DF5%40gmail.com.
Yup. I think burying markup in the middle of a function in a CFC is a bit grim, but if ppl want to do this: go for it. However if Lucee was to provide a new / different dialect in addition to CFM / CFC files (which is, remember, the plan here: tag-based CFCs are not going anywhere), I think it would be very poor decision to implement it as yet another tag-based language.
Sean and Kai, can you explain why component-based views seem like such a bad idea to you?
Igal Sapir
Lucee Core Developer
Lucee.org
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKd_k5y37p84EJ-2C09nyzDqyi8CKzVy32-OyjUJMvyB8w%40mail.gmail.com.
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.
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.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/0ec8da1f-c2d2-43e1-ac57-9aa2b98122a3%40googlegroups.com.
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.
this is like asking "why do we need functions or custom tags in the language when we can just write the function's body into a snippet and use cfinclude..."
there are times when you want to include a snippet/template, there are times when you want to use custom tags, and there are times when you want to use functions.
On 13 February 2015 at 00:32, Igal @ Lucee.org <ig...@lucee.org> wrote: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.this is like asking "why do we need functions or custom tags in the language when we can just write the function's body into a snippet and use cfinclude..."
No Igal, actually *your* position is more like that. Rolling disparate pieces of code into one location, instead of separating it out.
1. Funny, in another thread I was told by Micha that tag-based custom tags are bad and should not exist — that we all should use component-based custom tags because it’s all about the simplification and cleanup of the language…
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/F9D3D894-A4FC-48B8-B5EA-8C63C597426B%40gmail.com.
> In my opinion we need no prefix for tags, so simply
> <loop times="5">
> #now()# <!--- no output necessary! --->
> <dump var=now()> <!--- attribute values with no " are handled as expression, not strings! --->
> <br><!--- ignored and outputed as it is --->
> </loop>
> the tags Lucee does not know are simply ignored then.
Fair enough. I like _some_ prefix just because it makes it easier to find "code" in amongst the markup.
1) 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.
so you create a Renderer component where you put some of your rendering functions (the ones that apply to multiple pages, like so:
<cfcomponent name="UIRenderer">
<cffunction name="renderSmallWidgetThumbnail">
<cfargument name="widgetId">
<!--- code goes here to render html with thumbnail, name, price, etc !--->
</cffunction>
<cffunction name="renderLargeWidgetThumbnail">
<cfargument name="widgetId">
<!--- code goes here to render html with thumbnail, name, price, etc !--->
</cffunction>
<cffunction name="renderPagination">
<cfargument name="baseUrl">
<cfargument name="pageNumber" default="1">
<cfargument name="pageSize" default="20">
<!--- render links for pages 1 .. N or whatever !--->
</cffuntion>
</cfcomponent>
then on each page that uses those you can instantiate the component and call the functions, for example, on pages that show items thumbnails, you do:
Oh fuck off Igal.
I assure you that is not the chief difference between you (singular) and myself and Kai.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKcgcsghL-TZzz3zK_F0msqwCdbgHRXJs6PYyUVCs-620g%40mail.gmail.com.
right. you're also an asshole!Oh fuck off Igal.
I assure you that is not the chief difference between you (singular) and myself and Kai.
right. you're also an asshole!Oh fuck off Igal.
I assure you that is not the chief difference between you (singular) and myself and Kai.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/346FC818-E214-4A33-A908-9E3E8390D7C2%40gmail.com.
> 1) it proved to be much slower to begin with.
>
> 2) 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.
Ok, 1) and 2) are valid reasons from your point of view and that’s fair enough. However, those should be of no concern when it comes to spec’ing a new language as they’re implementation details of the Lucee server at this point.
If custom tags are slower now, that’d need be looked into and I’m sure there’ll be a way for better caching in a revised implementation of custom tags, too. Essentially, saying components are better/preferred because of the reasons mentioned is imho as bad as premature optimisation of code.
> 3) 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.
Playing devil’s advocate I could now say: Ok, let’s put everything for a page into one file, much easier to find stuff then, right?
Obviously it’s not that easy, but I personally think using an UIRenderer component with functions to create HTML is good architectural practice. I strongly think it’s the other extreme of putting business logic into your cfml page template. If you chose to do that, that’s your option, but a new language shouldn’t endorse that at all but instead opt for a clear separation between what the respective components of the language are good at.
Playing devil’s advocate I could now say: Ok, let’s put everything for a page into one file, much easier to find stuff then, right?
On Feb 12, 2015, at 12:56 PM, Michael Offner <mic...@lucee.org> wrote:
> 2. supporting tag islands in script
This was something I pushed for on the CFML Advisory Committee and I still think is a good idea, if we can agree on a nice syntax for it. I’d be OK with {{: … :}} but I’d like to see some other suggestions.
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.
<widget:thumbnail size="small" id="#widgetId#"/>
<widget:thumbnail size="large" id="#widgetId#"/><widget:pagination pagesize="20" pagenumber="1" baseurl=".."/>
<html>
<head><title>...</title></head>
<body>
<cfscript>
oUIR = new UIRenderer();
for (var widgetId in searchResults)
oUIR.renderSmallWidgetThumbnail(widgetId);
</cfscript>
<div>other content...</div>
<footer>
<cfoutput>#oUIR.renderPagination(...)#</cfoutput>
</footer>
</html>
<cfimport taglib="/tags/widgets" prefix="widgets"/>
<html>
<head><title>...</title></head>
<body>
<cfloop query="#searchResults#">
<widget:thumbnail size="small" id="#widgetId#"/>
</cfloop>
<div>other content...</div>
<footer>
<widget:pagination pagesize="20" pagenumber="1" baseurl=".."/>
</footer>
</html>
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.
Then let's focus on creating a platform that is awesome at the other 99%. Making quality compromises for the 1% edge case, which is arguably poor design to begin with regardless of the claim that it was borne out of performance issues is not a way to design a new language. CFML has plenty of those poorly decided "features" already and if someone wants to make use of those then they can still do it in legacy tagged base cfc, but for a new dialect, specifically .lucee I think it would be a bad call.
I've developed many sites (e-commerce and otherwise) that require thumbnails, reusable html blocks, etc..
and I have never, ever had issues with using custom tags as a solution. Granted, most of that was with ACF, so perhaps Railo/Lucee has an issue and just needs a better custom tag implementation?
Consider the following alternatives to your functions:
<widget:thumbnail size="small" id="#widgetId#"/>
<widget:thumbnail size="large" id="#widgetId#"/><widget:pagination pagesize="20" pagenumber="1" baseurl=".."/>
Doesn't that provide better reusability?
Let's not let the 1% use case dictate the direction the language goes. Please.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/47d84ac6-4b54-4a9d-be55-79fde7a61689%40googlegroups.com.
I don't understand why the insistence to remove features that you guys don't like.
this.componentpaths = [{archive:"http://ortus.com/latest/testbox.lar"}];
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.
On Thursday, February 12, 2015 at 2:25:29 PM UTC-8, Igal wrote:I disagree.
there are many times where tags makes sense in a component.
while most of the components (and even in templates) I write cfscript, in most projects I have a component named UIRenderer, which contains many reusable functions for rendering elements. that way the rendering output is centralized, maintainable, and consistent across the project.
island tags would be my preferred way, since I would be able to use script for the rest of the component, but there is definitely room for html tags in components. unfortunately, as it is now, you can have an island script in a tag based component, but not the other way around.
and the fact that there are frameworks out there is irrelevant. I don't use any of those, and for the foreseen future I don't intend to start.
On 2/12/2015 2:08 PM, Adam Cameron wrote:
On 12 February 2015 at 19:38, Dave Merrill <enig...@gmail.com> wrote:
Sean and Kai, can you explain why component-based views seem like such a bad idea to you?
You didn't ask me, but that's never stopped me before.
I think there's sufficient frameworks out there that allow one to separate views out into separate view templates, it's almost more a case of why would you want to put your views into a CFC file?
Each view is best stored by itself, so that ppl maintaining the view - who are often UI devs not business logic devs - have less scope for... erm... "getting confused", and it's also a more familiar paradigm: a view file is more similar to a web page than a component with a function with a view in it.
Also a view should be as simple as possible. One of the main tenets of MVC is separation of logic; with the view being purely display layer. So the less logic a view has, the closer it is to being an ideal view.
So the closest one could get to an "ideal view" would be to have one view per CFC. Which means that one is left with a bunch of irrelevant boilerplate code in there to define the CFC and the function, and the arguments etc before getting to the code that actually matters to the view.
And why do that if one can just do the view in a CFM file, and leave it to simply get on with being a view?
One can drive a screw in with a hammer rather than a screwdriver. And that works. But there's more to "it working" than the end result being "the screw is now embedded in the wood".
--Adam
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKd_k5y37p84EJ-2C09nyzDqyi8CKzVy32-OyjUJMvyB8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/a523ef43-f4f2-4777-9ee2-2f14402579c6%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/BEF9AFA4-67FD-4EE5-86B3-2098B935076B%40gmail.com.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKfTuQXEpB5HOYCPW4GO6AP8HPr6UrJia3LLXBNndfNA%2BQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKfnrRrnSfH2Lm7M3z9mv-ApvC-5nquq0%2BwvF57WEfDyFg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKdjjFUVBGX%3DEPBkuW%3DbOnL-0s9xPb1E36LM1vdLAgiHfw%40mail.gmail.com.
> 1) 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.
> 2) Kai -- the fact that you don't understand something doesn't make it bullsh*t. 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 bullish*t 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.
> 3) 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
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/BC3F190A-2FCF-4F47-A179-C148A86BE835%40gmail.com.
Cheers
Kai
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/A08CB133-72E9-4B3C-8F9B-4CE4633EEC8F%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBwDBgDBPRcSMCvcqKyy1Xqw4vyDutO112qPo-p1N%2BgaNw%40mail.gmail.com.
|
|
CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB |
<form:field type="text" name="username" value="" message="Enter your username">
<form:field type="datepicker" name="birthdate" value="01/01/1982">
...
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBzVDffcoPPv8cvvtQRMHRSPOfVcNXhXT%2BzZDDzRC3eQfQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAEYvUx%3Ddj3g1txWR0AA-YT68ms%3D6xA9XpUXT%2BD%3DDmknXfyqqKQ%40mail.gmail.com.