Might want to re-post your question if you haven't already on the discourse forum (http://lucee.org:8080/) which will eventually be http://discourse.lucee.org as they aren't going to be using this google group any more in favor of Discourse.
--
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/5e6973b6-2978-43a8-b442-5fd286c4e1b7%40googlegroups.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/CANPdUeZ7VschDOjaQcg1xz4%2BZEpYtjVdvzOO7aN8VnrtWPYxkA%40mail.gmail.com.
Hi Andere,
I would also like an official clarification as to what it means, we can all assume that it means the removal of the "dumbest tags ever to be created"(tm) but if they start breaking backwards compatability or inconsitencies in how the old core cfml tags work we are also going to have some major problems. Our software is designed to work equally good with both Adobe as well as Railo/Lucee. The more the languages differ from one another the harder it is for us to maintain and manage, and the more code branches we will need. So I am truly hoping that its only the crappy front-end tags that will be dropped.
I would also like an official clarification as to what it means, we can all assume that it means the removal of the "dumbest tags ever to be created"(tm) but if they start breaking backwards compatability or inconsitencies in how the old core cfml tags work we are also going to have some major problems. Our software is designed to work equally good with both Adobe as well as Railo/Lucee. The more the languages differ from one another the harder it is for us to maintain and manage, and the more code branches we will need. So I am truly hoping that its only the crappy front-end tags that will be dropped.
--
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/674c3949-887e-4bc0-9ace-53730efa3d9c%40googlegroups.com.
On Feb 5, 2015, at 10:59 AM, ADK <and...@leftbower.com> wrote:
> This is such a tricky subject.
Indeed.
> However, I imagine - and perhaps I am completely wrong - that Lucee hopes to (eventually anyways) grab members from the ACF community to "seed" its base.
I’m not so sure.
--
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/0850BFD8-6A7D-4702-BAC4-CE1B8232D8A1%40corfield.org.
Moving stuff to extensionsSo first of all the facts, Lucee 5 is moving a lot of stuff out of the core to extensions, this includes- ORM (Hibernate)- Search (Lucene)- Form tags (YES!!!)- Datasources (don't be afraid, some of them are preinstalled)
depreciation framework
So what could be the medium for Lucee, that is very simple, the medium are templates (.cfc,.cfm).What if Lucee acts different depending on the file extension.
Re: lucee extension - I think that's a great idea!
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/30f354ad-9802-4747-a179-b2aeae4f6ff2%40googlegroups.com.
On Feb 5, 2015, at 12:14 PM, Andrew Penhorwood wrote:
> Pascal died back in the 80s.
I shed a tear for it’s passing - it was the first programming language I learned in depth, back in ’79 (I’d done a little Algol 60 before then).
Moving stuff to extensions
depreciation framework
ACF compatibility
- .lc would be a nice extension if it's not commonly used. I'm imagining typing .lucee 10,000 times..
On Feb 5, 2015, at 7:44 PM, Jas Panesar <jas.p...@gmail.com> wrote:
- .lc woul be a nice extension if it's not commonly used. I'm imagining typing .lucee 10,000 times..http://filext.com/file-extension/LC
Sean Corfield -- (904) 302-SEANAn Architect's View -- http://corfield.org/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
--
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/AB97FB08-2EC5-4DC8-B69B-2823EF1384BB%40corfield.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/7CE7DAB7-0197-49C7-9077-C5BEA5DFA060%40corfield.org.
- .lc would be a nice extension if it's not commonly used. I'm imagining typing .lucee 10,000 times..
What if Lucee acts different depending on the file extension.So all templates with .cfm and .cfc extensions are still handled the old way, but files with the extension .lucee are handled in a modern way.
--
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/51c4ec07-65dc-498a-a507-423c13e0e5a3%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAB1Zp0Jt%2BnuXqP0GxBpW%2BO4mqcPwV-n6sycFRMjTEw%2Bgz%2Bq-QQ%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/e19dfb9d-9ee7-4b54-a8a2-1611f122dd7d%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/2164a6ad-0660-4458-90e4-b39199b226c2%40googlegroups.com.
it is not my intention to call it ".lucee"
Agreed. Besides, if a real IDE is supported, no one will ever have to type the extension, anyway. I'm not sure I've ever typed ".groovy" other than just now in this email.
> --
> 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/58a52c64-ff77-48f2-8beb-27597d657fa7%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAKa5oqJ9KWRrNX1-BK3gpYY_Dvze_4mfrKAg8kjhgUMgBDg%3Dqg%40mail.gmail.com.
Sorry for the misunderstanding, Micha, but I thought it was pretty clear that the vast majority was very much in favor. There'd be no other reason to discuss the extension. :-)
To be extra clear, I personally could not possibly be more in favor of the idea of moving forward and leaving Adobe completely in the dust so that "outsiders" can be enticed to give it a try, and this idea is quite likely the best way to do just that.
> To infinity and beyond!
:-)
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBzRBWE2Ju-sS5Vx%3D8bYjKymWrdK4gC8uCLg4VWRQUzRjw%40mail.gmail.com.
it's funny, no body is discussion about the general idea, only about the extension for it ;-)It's like we asked if we should get a new car and everybody is already discussing about the color of the car.Adam asked what "what if" means, if this is already in the pipeline or just a idea?If the community likes the idea, we go for it! technically there are no hurdles we cannot cross.
--
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/CAG-7QUtvrzAyh4AiVYGRCcNVMmSw0rMXOz5totSbS8QEzycFEg%40mail.gmail.com.
On 6 Feb 2015, at 11:27, Adam Cameron <dac...@gmail.com> wrote:I didn't see any point in discussing it further prior to clarifying whether you were simply speculating, or whether it was going to happen. Which you still haven't. If it was merely a "what if...?" then my reaction is "lovely, but can we discuss something concrete pls, otherwise we're just wasting our time”.
And the file extension "conversation" only cropped up because someone admitted being too lazy to type five characters for a file extension. I didn't think it needed conversation at all. The extension should be ".lucee", and should be the same for both class and view files.
Still: ppl like chatting... there's nothing wrong with that.
If I ruled, [...]
On 6 Feb 2015, at 11:34, Adam Cameron <dac...@gmail.com> wrote:If I ruled, [...]People would revolt.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAKa5oqJteSmBfR18uq%3D4%3D0tmoSEvhpsRKbvhNNJGbw4BchrC-Q%40mail.gmail.com.
Just my 2 cents, but why worry the extension name at all...make it a setting in the Serve and/or Web admin so that people can use whatever extension they want forneach of the 3 file handlers (CFML, CF Component and Lucee). Use a comma delimited list or something.
--
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/51286f55-fc10-472e-b543-e60520891aa8%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/CAFwR%2BKdKWfeSMSpUFSNEcBiEJsiOwYDV-3BWApoCX3Qu3xZebg%40mail.gmail.com.
about the extension, it is not my intention to call it ".lucee" that was just to make it clear that there could be a lucee specific extension.so let's think about it:Distinction between component and templates?So the first question is, do we need a distinction with the extension?
It is going to happen if the community wants it to happen. That is people discussing it. So you have to throw ideas out there to the community. Micha did say: "If the community likes the idea, we go for it! technically there are no hurdles we cannot cross.”On 6 Feb 2015, at 11:27, Adam Cameron <dac...@gmail.com> wrote:I didn't see any point in discussing it further prior to clarifying whether you were simply speculating, or whether it was going to happen. Which you still haven't. If it was merely a "what if...?" then my reaction is "lovely, but can we discuss something concrete pls, otherwise we're just wasting our time”.
On Thu, Feb 5, 2015 at 9:17 PM, Sean Corfield <se...@corfield.org> wrote:
On Feb 5, 2015, at 12:14 PM, Andrew Penhorwood <penho...@gmail.com> wrote:
> Pascal died back in the 80s.
I shed a tear for it’s passing - it was the first programming language I learned in depth, back in ’79 (I’d done a little Algol 60 before then).
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
--
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/0850BFD8-6A7D-4702-BAC4-CE1B8232D8A1%40corfield.org.
Keep in mind too that some sites try to hide the technology they use, so they configure the web server to process .html files as CFML.
--
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/D72E9A4B-C4D4-4790-B0A0-604AC6DDB81C%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG1WijVoWdDah%3Dskwy2HzGkJ4NYU2Ypj%2B8gjdy9qxGt6NOzH-g%40mail.gmail.com.
Hi Everyone,Exciting to see some new development in the Railo/CFML space!It looks like this new community driven effort is a great direction.As an outsider Railo seemed like it had great developers but no organization (for example the two separate sites that were rarely updated just made things confusing.)We run a fairly large site on railo and have been very happy with it (switched from CF to Railo over a year ago).Unlike a lot of the frequent posters we are not involved at all in the development community and so have very little idea of what the plan was for Railo 5.0 and beyond.In Adam Cameron's (http://blog.adamcameron.me/2015/01/lucee.html) post I saw this among the roadmap for Lucee's future:"Being bolder about backwards compatibility deprecating old style CFML and pointless frontend tags"Could someone please elaborate on what it means?Not sure what is meant by old style CFML and frontend tags.While we do keep up with development and switch to new tags on newer projects, we do have a lot of old code with deprecated tags that work fine, and the vast majority of our code base is still cf markup tags. Just wondering how we fit in with Lucee's future development roadmap.Thanks,Stephan
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/396EA750-6702-4E72-A815-8DDD99C80D0A%40gmail.com.
I think the concept is an excellent idea. Also, I like the idea of .lucee or.luc for the extension, and I see no need for separate extensions for templates versus components.
<ul>
<% @users.each do |user| %>
<% end %>
</ul>
--
You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/5Ol7vTOm6Gk/unsubscribe.
To unsubscribe from this group and all its topics, 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/CACtg%3DUKCdq-aw_iO-UtbHPk3xaaFV989B5iTvu5yBveJX49GYA%40mail.gmail.com.
On Feb 5, 2015, at 10:59 AM, ADK <and...@leftbower.com> wrote:
> This is such a tricky subject.
Indeed.
> However, I imagine - and perhaps I am completely wrong - that Lucee hopes to (eventually anyways) grab members from the ACF community to "seed" its base.
I’m not so sure. At this point, the Railo user base is pretty good and those folks will, as you said, happily make the move to Lucee and follow on down that path. Railo’s been a solid, free open source option for five years now and many ACF shops have migrated. Those that haven’t fall into a couple of categories, in my opinion:
* Too corporate / too entrenched to consider migration to FOSS at all.
* Too heavily reliant on ACF-specific features that they can’t move to Railo/Lucee (without a HUGE amount of effort).
So, whilst I think there may continue to be a slow trickle of migrations from ACF to Lucee, I think that ship has sailed… That means Lucee needs to draw developers from a wider pool going forward, and that means disconnecting from the stigma that is "ColdFusion" in the eyes of most of the world (I mix with a lot of developers in other languages and the favorable responses to the word "ColdFusion" are extremely few and far between - even tho’ most of the negativity is based on pre-JVM-rewrite timeline knowledge!). Any one of us who has interacted with developers in other communities knows how much disdain there is for both "ColdFusion" (the language / product) and for CFML developers in general.
> I wonder how likely it is to be an impediment or pause for concern for those still in the ACF community to make the jump or even test the waters?
It will be an impediment, yes. But I think there’s far fewer likely to jump ship now than there were. And many ACF shops will be looking to jump to a non-CFML technology when they do jump, to "get away from ColdFusion". In many ways, Lucee would be more attractive to those shops if it was seen as a clean break, a successful FOSS language not dragged down by the baggage associated with "ColdFusion".
> I think the greater that cost of switching, the more likely I would strongly consider another more established language that would make my business life simpler - and frankly more stable - down the road.
At World Singles, we’re in the middle of that process: we have 90kloc in CFML (+ 5kloc tests), which is Railo-specific (we switched from ACF five years ago), and we have 25kloc Clojure (+ 8kloc tests) which is our targeted language. We picked Clojure because it is a modern language that provides immutable data by default (which is awesome for concurrency) and a lot of powerful abstractions. Clojure first appeared in 2007 and in terms of jobs is currently smaller than ColdFusion - but Clojure is growing and ColdFusion is shrinking. Clojure’s *community* is much larger and much more active than what’s left of the CFML *community*. So I wouldn’t call Clojure a "more established language" but there are plenty of options that can make a business’s life simply and more stable. We live in a polyglot world where more and more new languages keep appearing all the time. They are often modular and interoperate really well.
If you’re looking for a "more established language" then you’d want to be moving away from CFML altogether and not considering a migration to Railo or Lucee - which was kind of my point above: those folk won’t come our way, they’ll go to Java or .NET or PHP.
> What's the plan to garner that all-important critical mass to get this thing to the next level and beyond?
See my comment about new languages above. A language doesn’t need to be wildly popular to be successful, it just needs to be good enough to attract folks from other languages - by evolving into something that is better (for those folks) than other languages. CFML definitely is not that sort of language, but Lucee could grow to be.
What’s being suggested is that CFC/CFM support continue to be in "Lucee" (the ecosystem) but maybe as an extension (that is fully supported and is easy to install). No one is actually proposing that handling of CFC/CFM files changes.
The point about "killing the CF baggage" is mostly to find a way to make Lucee appeal to a broader audience - i.e., non-CF developers - and to do so without the stigma of "being a CFML engine". Lucee is a scripting / templating system for the JVM (that just happens to also run your legacy CFML code).
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/lucee/7f893ad3-0992-4e0f-a94f-acc52b42d0ea%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/c25d3daa-5bc3-49be-ae30-fee4c333ee81%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/6600E10D-902F-4633-B347-10C790BEC748%40corfield.org.
Yeah, but who says that this will not be the case with a .lucee, <cfoutput query...> will be valid in cfml but for sure not in .lucee.
ACF compatibilityACF compatibility is still very important for Lucee in my opinion. today you can decide between being compatible and having it the right way with settings in the admin, that is not really handy!But we you think about this:Take as example a DVD player *, part of the DVD specification is that they must be able to play CDs, so every DVD player can also play CDs, means every DVD player is also a CD compatible.Only the medium you use makes the difference, you don't have to change hundreds of setting in your DVD player to play a CD.So what could be the medium for Lucee, that is very simple, the medium are templates (.cfc,.cfm).What if Lucee acts different depending on the file extension.So all templates with .cfm and .cfc extensions are still handled the old way, but files with the extension .lucee are handled in a modern way. this gives you the opportunity to still use your old code but you can extend it with new one and you have no confuguration nightmare anymore!
I am also an old style classic cfml coder since the 90ies (like some others here), using really old cfml tags. My old CFML now works with Railo thanks to its classic support, but now I really don't know its future with Lucee anymore. It really looks to me that the focus is shifting towards a new language from now on, shifting away from CFML. By the way, I still use a lot of <cfoutput query>.
Even if it is being said: CFML will mainly work and be supported with .cfm on Lucee, now I know the teams focus will be on a new type of LuceeScripting- or LuceeMarkupLanguage.... so on the long run I understand that I'll have to recode my stuff into some sort of LuceeML just to be on the safe side.
Do Lucee will attract new developers? Some for sure, but I will have to rethink switching to ACF or even BlueDragon over Lucee. Why not Lucee?
Just a little example is the history of Railos documentation: There was a documentation in Railo about Tags and Functions etc. But it was very rarelly updated, rarelly complete, and poor in content. And it even was offline or not working for a period of time... Yeah... Most of the time I had to dig into ACFs documentation to look for functions and tag attributes for railo, I even looked in Fortas CFs books. And how will that be with Lucee? If Lucees docs will be like Railos, that will be a very tough start to attract new developers. ACF docs complemented Railos a lot and that gap will have to be filled.
Another example was the installation: I remember when I've tried to install Railo for the first time... it was 3.x on a WIN machine with IIS, and there wasn't any installers or docs about it. It was a real pain to make Railo work. Fortunately there was an outside blog post that someone of the railo community made and linked to. And even with Railo 4.x it is still a pain making it work on WIN and IIS.
From my side, I will rethink our decision, and may be switching back to ACF, or even switch to BlueDragon, because what I was looking for was classic CFML, not a new LUCEEML. And that focus seemed to have changed on the old-Railo-new-Lucee-Development-Team now, and from my perspective the risk of cfml support being switched off in lucee in future with a sudden announcement has risen a lot... and that was not what I was looking about when I've jumped on Railo.
The sudden anouncement that Railo stopped its development, and now is Lucee feels like a bomb thrown into what was giving me real confidence in the future of CFML.
--
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%2BKcL_zM33dBH9jWUzAs4btywZd9kxJzm4o%3D5T8ZW1LhL_A%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/fa1fa9df-cbc1-4fa6-a8b3-fe1889b1ca92%40googlegroups.com.