what's new in 2.0

[<jorge_loyo>]

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.

[Peter J. Farrell]

The list of features for 2.0 is just tentative, not set in stone -- just
ideas we have floating around.

Page-views by convention would let you use a page-view loader (bundled
with the framework, or write your own). This would let you do:

<page-views>
<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"/>
<page-view name="products.widgetC"
page="/views/products/widgetsC.cfm"/>
<page-view name="home" page="/views/home.cfm"/>
</page-views>

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:

[<jorge_loyo>]

very nice... I like this a lot. page-views & listeners sections would
definitely be a lot more compact.

[Peter J. Farrell]

<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:

<page-views>
<page-view-loader type="MachII.framework.PageViewLoader"
path="/views/products/**/*.cfm" nameBase="products" />
</page-views>

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"/>

You could define multiple loaders if needed.

.Peter

[<jorge_loyo>]

Right now, I have 34 folders inside my "/views" folder (large app)...
so this would be a very nice addition.

Were you guys considering giving the option of:

<page-views loader="MachII.framework.PageViewLoader" rootPath="/
views" />

and something like:

<page-views>
<page-view-loader type="MachII.framework.PageViewLoader" path="/
views/products/**/*.cfm" nameBase="products" />
</page-views>

Or one or the other?

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".

[Brian Meloche]

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.

--
Sincerely,

Brian Meloche
brianmeloche at gmail dot com
Blog:  http://www.brianmeloche.com/blog/
Adobe Community Expert:
http://www.adobe.com/communities/experts/members/BrianMeloche.html
Pownce:  http://pownce.com/bmeloche
User Group Manager,
Cleveland ColdFusion Users Group,
http://www.clevelandcfug.org
Co-Manager,
Cleveland Adobe Users Group,
http://www.clevelandmmug.org

[Peter J. Farrell]

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:

[Zack Pitts]

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...@googlegroups.com [mailto:mach-ii-for...@googlegroups.com] On Behalf Of Peter J. Farrell
Sent: Monday, May 05, 2008 4:55 PM
To: mach-ii-for...@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 J. Farrell]

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.

.pjf

[<jorge_loyo>]

"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:

http://dev.app.com/showproduct_product-1001.html

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.

<event-handler event="parse404" access="public">
<filter name="404Filter"/>
</event-handler>

<event-handler event="showproduct" access="public">
<notify listener="productListener" method="getProduct"
resultArg="product" />
<view-page name="productForm" />
</event-handler>

I would like to see what "custom SES urls" include. very exciting...
very very exciting.

[Kyle Hayes]

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:

[<jorge_loyo>]

Hi Kyle,

I do take advantage of the custom url creation with v1.5. This is my
actual setup:

<property name="urlBase" value="/index.cfm" />
<property name="moduleDelimiter" value=":"/>

<property name="urlParseSES" value="true" />
<property name="urlDelimiters" value="/|/|/" />

The problem we encounter is that mgmt does not want to see any CFM as
part of the url for fear of being negatively affected by the search
engines...

So instead of :

www.site.com/index.cfm/go/showproducts/

they would like to see:

www.site.com/go_showproducts.html

to make it more readable for visitors and for search engines. However,
since there is no CFM as part of the url, this is why we were testing
with the 404parser event-handler...

[Kyle Hayes]

Oh I see what you are saying now!

--
Kyle Hayes
kylehayes.info/blog
www.linkedin.com/in/kylehayes

"It's kind of fun to do the impossible." -Walt Disney

[Matt Woodward]

The fact that "cfm" is in the URL will not have any negative impact on
the search engines. If your management is that particular about URL
formatting you should really be using mod_rewrite.

--
Matt Woodward
mpwoo...@gmail.com
http://www.mattwoodward.com

Please do not send me proprietary file formats such as Word,
PowerPoint, etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html

[<jorge_loyo>]

> The fact that "cfm" is in the URL will not have any negative impact on
> the search engines. If your management is that particular about URL
> formatting you should really be using mod_rewrite.

Thank you Matt.

I will let mgmt know that, the fact that the url includes cfm as part
of it won't affect the traffic.

[Matt Woodward]

I think that's just a hold-over from WAY back in the early days of
search engines. Many of the things people got in their heads about SEO
are no longer true, so it's always worth a refresher as this stuff
changes. I'm by no means an expert, but I'd guess that the opinion
that cfm in the URL will impact search results stems from the fact
that some engines used to (like 10 years ago) not index "dynamic"
pages.

--

[Zack Pitts]

Our company does SEO for our client's Web sites. I don't know much about
that aspect of the business, but it's been explained to me that a .htm(l)
file extension is treated as a physical document by the search engine. So
we use ISAPI Rewrite to transform all URLs to a content-rich hierarchy of
page names with a .htm extension.

This creates a weird interface between our public-facing URLs and our CMS.
For example, a page in the CMS that is organized under About Us > Our
Company > History would be exposed as

/About_Us/Our_Company/History.htm

ISAPI Rewrite sends the URL path to our CMS request handler, which parses
the path, looks up the corresponding content in the database and displays it
on screen. This creates a nightmare for us because we have to hard-code all
those rewritten URLs into form action attributes, hrefs, and the like. If
there were a way for us to interface this process with Mach-II's
URL-building functions, we could eliminate our dependency on these
hard-coded values.

However, I suspect that our process is a bit too customized for Mach-II to
accommodate without writing some additional components.

Zack

-----Original Message-----
From: mach-ii-for...@googlegroups.com
[mailto:mach-ii-for...@googlegroups.com] On Behalf Of Matt Woodward
Sent: Tuesday, May 06, 2008 9:49 AM
To: mach-ii-for...@googlegroups.com
Subject: [Mach-II] Re: what's new in 2.0

[<jorge_loyo>]

I know that engines do not like anything that contains a "?" since it
is dynamic content. This is the reason why we would like to use the
query string to create a fake html... so the engines think of it as a
physical page and not dynamic. However, I am not an expert in this
area either, so I will do a little more research.

[Zack Pitts]

On May 5, 5:28 pm, "Peter J. Farrell" <pe...@mach-ii.com> wrote:

> 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.

After having used buildUrl() extensively on my current project, I have
some ideas for additional features to make this an easier process. How
can I go about submitting these ideas?

Thanks,

Zack

[Peter J. Farrell]

File a ticket for 2.0 at trac.mach-ii.com

.Pjf


-----Original Message-----
From: Zack Pitts <folks...@hotmail.com>

Date: Fri, 23 May 2008 10:05:41
To:Mach-II for ColdFusion <mach-ii-for...@googlegroups.com>

Subject: [Mach-II] Re: what's new in 2.0

[Matt Woodward]

On Fri, May 23, 2008 at 1:05 PM, Zack Pitts <folks...@hotmail.com> wrote:
> After having used buildUrl() extensively on my current project, I have
> some ideas for additional features to make this an easier process. How
> can I go about submitting these ideas?

Great question Zack--you can submit any ideas you have on this or
anything else to our Trac site:
http://greatbiztoolsllc-trac.cvsdude.com/mach-ii/

[Zack Pitts]

Thanks for the direction, Matt. I have entered a new ticket (#32)
describing my proposed enhancement to the URL management features.

Zack