I was not able to attend cfobjective, but I kept checking out
different blogs and this group to get an idea of what was discussed
for Mach-II. This morning I read the "Whats new" PDF on the M2 site
and read a little about what is to be expected for v2.0
Excuse my ignorance, but what exactly does it mean "including
listeners and page views by convention". Sounds interesting and it
would sound even better if I knew what it actually meant :-)
I hope I can make it next year, but this year was impossible.
To this: <page-views loader="MachII.framework.PageViewLoader" rootPath="/views" />
It would use the directories and file names to build a "dot-style" path for the page-view names. Basically, it would load pages by using the path metadata to build useful page-view names. Also, if you have a different convention then the bundled loaders, you could write your own loader.
.pjf
<jorge_loyo> said the following on 5/5/2008 11:27 AM:
> I was not able to attend cfobjective, but I kept checking out > different blogs and this group to get an idea of what was discussed > for Mach-II. This morning I read the "Whats new" PDF on the M2 site > and read a little about what is to be expected for v2.0
> Excuse my ignorance, but what exactly does it mean "including > listeners and page views by convention". Sounds interesting and it > would sound even better if I knew what it actually meant :-)
> I hope I can make it next year, but this year was impossible.
<jorge_loyo> said the following on 5/5/2008 4:47 PM:
> very nice... I like this a lot. page-views & listeners sections would > definitely be a lot more compact.
More than likely we will let use some sort of ANT-style path selectors so it's not just an all for one effort and allows you some granularity. This is pseudo XML:
This would produce page-views at runtime that would be represented like this: <page-view name="products.index" page="/views/products/index.cfm"/> <page-view name="products.widgetA" page="/views/products/widgetsA.cfm"/> <page-view name="products.widgetB" page="/views/products/widgetsB.cfm"/>
If M2 created a dot-notation path to the files I would prefer to use
the first option. In what cases would you prefer to use the second
option? Seems like, if I decided to use it, I would define each of my
34 sub-folders with their corresponding "nameBase".
I love it (as you already knew, Peter). Default paths! Anything to reduce the amount of repetitive declarations and redundant code in the mach-ii.xml, so long as it doesn't add significant load times, is exactly what I want to see. It would be nice when a team of developers is working on a project to be able to reduce the number of changes required to the config file(s) during development. This will do that. Obviously, you still have to add the event-handlers, but it will be less work with these page-views and listeners by convention features.
On Mon, May 5, 2008 at 5:13 PM, <jorge_loyo> <jorgeloyo.accou...@gmail.com> wrote:
> If M2 created a dot-notation path to the files I would prefer to use > the first option. In what cases would you prefer to use the second > option? Seems like, if I decided to use it, I would define each of my > 34 sub-folders with their corresponding "nameBase".
Surprised that nobody has mentioned anything about custom SES handlers (i.e. custom SES urls instead of the default /key/value/ system that Mach-II 1.5+ offers)? I'm curious if anybody would use this?
.Peter
Brian Meloche said the following on 5/5/2008 6:42 PM:
> I love it (as you already knew, Peter). Default paths! Anything to > reduce the amount of repetitive declarations and redundant code in the > mach-ii.xml, so long as it doesn't add significant load times, is > exactly what I want to see. It would be nice when a team of > developers is working on a project to be able to reduce the number of > changes required to the config file(s) during development. This will > do that. Obviously, you still have to add the event-handlers, but it > will be less work with these page-views and listeners by convention > features.
> On Mon, May 5, 2008 at 5:13 PM, <jorge_loyo> > <jorgeloyo.accou...@gmail.com <mailto:jorgeloyo.accou...@gmail.com>> > wrote:
> Right now, I have 34 folders inside my "/views" folder (large app)... > so this would be a very nice addition.
> If M2 created a dot-notation path to the files I would prefer to use > the first option. In what cases would you prefer to use the second > option? Seems like, if I decided to use it, I would define each of my > 34 sub-folders with their corresponding "nameBase".
Our non-Mach-II CMS uses ISAPI Rewrite to translate content-rich URLs into usable ColdFusion variables, so we would have to create a custom handler if we redesigned the CMS for Mach-II. It would be nice to have some custom options built in.
Perhaps we could have a way to override the buildUrl() methods to implement our own custom handlers? That would be really, really great. If this is already possible without modifying the framework core files, please let me know.
Thanks,
Zack
From: mach-ii-for-coldfusion@googlegroups.com [mailto:mach-ii-for-coldfusion@googlegroups.com] On Behalf Of Peter J. Farrell Sent: Monday, May 05, 2008 4:55 PM To: mach-ii-for-coldfusion@googlegroups.com Subject: [Mach-II] Re: what's new in 2.0
Good to know Brian (as I already knew ;-).
Surprised that nobody has mentioned anything about custom SES handlers (i.e. custom SES urls instead of the default /key/value/ system that Mach-II 1.5+ offers)? I'm curious if anybody would use this?
Peter
Brian Meloche said the following on 5/5/2008 6:42 PM:
I love it (as you already knew, Peter). Default paths! Anything to reduce the amount of repetitive declarations and redundant code in the mach-ii.xml, so long as it doesn't add significant load times, is exactly what I want to see. It would be nice when a team of developers is working on a project to be able to reduce the number of changes required to the config file(s) during development. This will do that. Obviously, you still have to add the event-handlers, but it will be less work with these page-views and listeners by convention features.
On Mon, May 5, 2008 at 5:13 PM, <jorge_loyo> <jorgeloyo.accou...@gmail.com> wrote:
Right now, I have 34 folders inside my "/views" folder (large app)... so this would be a very nice addition.
If M2 created a dot-notation path to the files I would prefer to use the first option. In what cases would you prefer to use the second option? Seems like, if I decided to use it, I would define each of my 34 sub-folders with their corresponding "nameBase".
Zack Pitts said the following on 5/5/2008 7:18 PM:
> Our non-Mach-II CMS uses ISAPI Rewrite to translate content-rich URLs > into usable ColdFusion variables, so we would have to create a custom > handler if we redesigned the CMS for Mach-II. It would be nice to > have some custom options built in.
> Perhaps we could have a way to override the buildUrl() methods to > implement our own custom handlers? That would be really, really > great. If this is already possible without modifying the framework > core files, please let me know.
Currently there is not a way to override the BuildUrl() method. We were thinking that BuildUrl() wouldn't need to be modified in the terms of API of that function, but be able to build a different type of URL (based of the event and module name). Mach-II would select which builder to use based criteria. Examples to come on how I envision this will be implemented when I have a more concrete example for you.
"Surprised that nobody has mentioned anything about custom SES
handlers (i.e. custom SES urls instead of the default /key/value/
system that Mach-II 1.5+ offers)? I'm curious if anybody would use
this?"
I would definitely be interested in seeing some examples of what this
could potentially do.
We ran a few tests with our application, for example:
We omit the "index.cfm" and we use the key/value pairs as a fake html
page "showproduct_product-1001.html". Then we change the default IIS
404 handler page to be "http://dev.app.com?event=parse404". This event-
handler calls a filter that strips the first item in the list and uses
it as the desired event and the rest of the items are used as the
event arguments to be used. This filter then announces the desired
event.
Jorge, if I understand you correctly, you think that the current 1.5+
setup is not custom, but actually, it is:
<property name="urlParseSES" value="true" />
<property name="urlDelimiters" value="/|/|/" />
The urlDelimiters property is separated by the pipe, so you can
customize the what characters are used for the separate of attributes.
On May 6, 7:19 am, "<jorge_loyo>" <jorgeloyo.accou...@gmail.com>
wrote:
> "Surprised that nobody has mentioned anything about custom SES
> handlers (i.e. custom SES urls instead of the default /key/value/
> system that Mach-II 1.5+ offers)? I'm curious if anybody would use
> this?"
> I would definitely be interested in seeing some examples of what this
> could potentially do.
> We ran a few tests with our application, for example:
> We omit the "index.cfm" and we use the key/value pairs as a fake html
> page "showproduct_product-1001.html". Then we change the default IIS
> 404 handler page to be "http://dev.app.com?event=parse404". This event-
> handler calls a filter that strips the first item in the list and uses
> it as the desired event and the rest of the items are used as the
> event arguments to be used. This filter then announces the desired
> event.