Who Has Tried Mach-II 1.8 BER?

[Peter J. Farrell]

Just thought I would get a quick show of hands of who has tried Mach-II
1.8 and maybe include the feature you've found to be the most beneficial
or flashy (sometimes the most beneficial is pretty mundane while the
most flashy is useful but does not rank at the top of the most
beneficial list). I know that Team Mach-II is would be interested to
hear what people have to say so feel free to reply to this thread.

You can get the latest nightly zip of 1.8 at
http://www.mach-ii.com/nightly/ Also, the website now lists in the
right hand column (on any page but the blog or home page) the date of
the last nightly that was published for your convenience. And if you
haven't tried out 1.8, be sure to visit the wiki at
http://trac.mach-ii.com and read up on what is going on.

Remember, our moto "We're Community Driven". It's not just a catch
phrase, we live it here at Mach-II. We can't make great quality
software without you!

.Peter

P.s. I'll be typing out a project update soon.

[Jorge Loyo]

Peter,

I have been using the 1.8 BER for my current project.

The features that I am currently finding extremely useful are:

1) View-Loaders:
A LOT less code in my xml files. I loved to see how easy it was to
create a new CFM page and not have to define it, but simply call it
from my event-handler.

2) Call-Method:
It's incredible to see the number of methods I had in my listeners
that were merely forwarding the request to my service layer. Now my
listeners are lean and mean. :-)

3) redirectEvent:
THANK YOU!!! That's all I can say. I love this feature as with the
combination of event-mapping has helped me eliminate a lot of extra
event-handlers that simply perform a redirect.

4) EnvironmentProperty:
Before, this feature I never felt completely comfortable with the way
we were handling the environment specific variables... this is a very
welcome addition.

5) HTMLHelperProperty
I love this, as now I use addAssetPackage to include my Spry and
SexyAlertBox... Also, adding my page-specific javascript files via
addJavascript() is very nice.

These are the ones that I have been using the most... Keep up the work
guys. M2 has come a long way.

[Brian FitzGerald]

I have also been using 1.8.

My favorite feature is the EnvironmentProperty. It rocks! It was
pretty ugly how I was handling that stuff before. I am also using
redirectEvent, view-loaders, and the HtmlProperty. Loving all the new
additions. The only thing I think the HTML prop is missing is built in
combining and compressing of JS and CSS files.

Haven't had a chance to try call-method - I know I have a need for it,
just haven't plugged it in yet!

[Peter J. Farrell]

Good to hear Brian and Jorge what you are using. BTW, it is on our
list to add support to the Dashboard to reload view-loaders
dynamically as well since you've both mention that feature. As an
aside, I'm using that feature pretty heavily in my own applications --
not only does it almost eliminate the page-view section (usually to
just a a few lines of configuration xml), but it also forces you to
use good conventions for naming and organizing your views.

Believe it or not, but the AntPatternMatcher.cfc (which drives the
pattern matching abilities of the view loaders) was not the easiest
thing to port into CFML (it is a port from an ANT library).

As for the HTMLHelperProperty suggestion on compressing and combining
files, that's a little taller order to accomplish -- not impossible,
but just a little harder to engineer (keyword is engineer *well*). It
is something on the list to do in my head, but Brian would you do me a
favor by filing a ticket (http://greatbiztoolsllc.trac.cvsdude.com/
mach-ii/newticket) so this idea doesn't get forgotten. I usually
encourage people to bring it up on this list (or on the M2 development
list if it's more of new feature instead of "this is a logical
improvement" suggestion).

I think the hard part of engineering this suggestion well is due to a
few things:

1) While we could leverage some Java packages here, it would
completely complicate installation of Mach-II if people have to start
dropping in jars into the CF class path. I did start a port of JSMin
from Java into CFML which could compress JS files, but I haven't had
time to track down some defects in my port.

2) Not all compressors work the same and are destructive. Which one
do we choose? It might be better to create a pluggable infrastructure
and if people can't add in there favorite compressor due to server
restrictions -- they would be just out of luck (this would be done via
some adapter).

3) File catenation is a little time intensive so we'd have to build in
some sort of caching to the system so we don't compress and catenate
on each and every request.

Brian, any thoughts on what you think of this?

[Mark Mandel]

> I think the hard part of engineering this suggestion well is due to a
> few things:
>
> 1) While we could leverage some Java packages here, it would
> completely complicate installation of Mach-II if people have to start
> dropping in jars into the CF class path.  I did start a port of JSMin
> from Java into CFML which could compress JS files, but I haven't had
> time to track down some defects in my port.

Why not load it up with JavaLoader?

--
E: mark....@gmail.com
W: www.compoundtheory.com

[Sami Hoda]

I have NOT used 1.8 yet, but just to add, we use a custom combination
of 2 seperate riaforge libs to combine JS and CSS (and to handle
related to doing just that.) So following the enhancements, they looks
great, but yes using JavaLoader would be cool.

I guess this all furthers the theme of making this easier and taking a
lot of manual work out of the equation, and the question is how far do
you go, especially when it involves integration with other code.

> E: mark.man...@gmail.com
> W:www.compoundtheory.com

[Brian FitzGerald]

Hey Peter, you're certainly a mile ahead of me on this one -- I just
thought it was be cool, I didn't know that it would actually take
work! But you're right, there do seem to be quite a few
considerations wrapped around it. I went ahead and filed it as an
enhancement request here: http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ticket/274

>1) While we could leverage some Java packages here, it would
>completely complicate installation of Mach-II if people have to start
>dropping in jars into the CF class path. I did start a port of JSMin
>from Java into CFML which could compress JS files, but I haven't had
>time to track down some defects in my port.

I have looked at Aaron Lynch's custom tag cf_scriptilizer as a
potential solution, and I have also seen the "combine" project on
riaforge. Both seem like they may do the job, but both also have
associated jars. I'm not sure if we could use the code that's been
already written for these and roll them into a M2 solution somehow?
While I'm comfortable with it conceptually, my hands on java
experience is slim to none so I'm not sure how tough this would be to
implement. I definitely agree that we don't want to force people to
drop jars all over the place to install Mach-II. Maybe Mark's project
could help? (thanks Mark, for the suggestion)

>2) Not all compressors work the same and are destructive. Which one
>do we choose? It might be better to create a pluggable infrastructure
>and if people can't add in there favorite compressor due to server
>restrictions -- they would be just out of luck (this would be done via
>some adapter).

A pluggable infrastructure would certainly be the most flexible
option. I think this would be nice as long as the framework shipped
with at least one implementation... That way (if you weren't too
picky about it) you could just "set it and forget it" and let the
framework handle it on its own.

>3) File catenation is a little time intensive so we'd have to build in
>some sort of caching to the system so we don't compress and catenate
>on each and every request.

Could we handle this by appending the asset timestamps to the end of
the file path like the property is already doing for JS and CSS files?

Thanks for kicking this idea around w/ me!

Brian

[Peter J. Farrell]

Brian FitzGerald said the following on 4/9/2009 10:45 PM:

Hey Peter, you're certainly a mile ahead of me on this one -- I just
thought it was be cool, I didn't know that it would actually take
work!  But you're right, there do seem to be quite a few
considerations wrapped around it.  I went ahead and filed it as an
enhancement request here: http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ticket/274
  

Thanks for doing that Brian, as you can see -- I responded to that ticket with more thoughts before this message even came in.

1) While we could leverage some Java packages here, it would
completely complicate installation of Mach-II if people have to start
dropping in jars into the CF class path.  I did start a port of JSMin
from Java into CFML which could compress JS files, but I haven't had
time to track down some defects in my port.
    

I have looked at Aaron Lynch's custom tag cf_scriptilizer as a
potential solution, and I have also seen the "combine" project on
riaforge.  Both seem like they may do the job, but both also have
associated jars.  I'm not sure if we could use the code that's been
already written for these and roll them into a M2 solution somehow?
  

Yeah, I've looked at Aaron's project -- interesting on how it works.  I think if we add this -- we have a bit of research to do (like we always do) before we can find a great solution.  However I just want to point out that their are many ways to "skin" the cat (or for the vegetarians in the crowd -- peel a zucchini).  Some options bypass Mach-II / CFML entirely:

- Mod_concat for Apache does this and I bet it can do it faster than we can in Java and it's done at the webserver level
- If you use a more "scheduled" deployment system, you can create builds and concat files using ANT which makes the solution not at runtime concatenation, but a pre-compile solution

While I'm comfortable with it conceptually, my hands on java
experience is slim to none so I'm not sure how tough this would be to
implement.  I definitely agree that we don't want to force people to
drop jars all over the place to install Mach-II.  Maybe Mark's project
could help?  (thanks Mark, for the suggestion)
  

As I noted on my ticket comment, that this gets us into a problem of us shipping on older version of a JAR file etc.

2)  Not all compressors work the same and are destructive.  Which one
do we choose?  It might be better to create a pluggable infrastructure
and if people can't add in there favorite compressor due to server
restrictions -- they would be just out of luck (this would be done via
some adapter).
    

A pluggable infrastructure would certainly be the most flexible
option.  I think this would be nice as long as the framework shipped
with at least one implementation...  That way (if you weren't too
picky about it) you could just "set it and forget it" and let the
framework handle it on its own.
  

Yes, I think a pluggable solution would be better -- maybe we ship with "adapters" (that use a strategy pattern -- that extend a CFC for API), but make people choose the compressor they want by DLing the JAR etc they want.

3) File catenation is a little time intensive so we'd have to build in
some sort of caching to the system so we don't compress and catenate
on each and every request.
    

Could we handle this by appending the asset timestamps to the end of
the file path like the property is already doing for JS and CSS files?
  

Yeah, but we still have to manage the files that we write when concatenating them. The asset timestamp is for the web browser, we still have to delete / remove old concatenated files when we replace them with a newer version.

.Peter