Listener Location

[John Bliss]

Newbie, best-practice question: where should listener's live? In
reviewing sample apps and skeletons, two "schools of thought" appear:

/model/[Object]Listener.cfc
/listener/[Object]Listener.cfc

Reason(s) to choose one over the other...?

[Vipul Suri]

second option - /listeners/[Object]Listener.cfc

--
Best Wishes,
Vipul Suri

[jlcox]

Heh, mine are actually /model/listeners/[Object]Listener.cfc

[Prem Radhakrishnan]

its a matter of preference

Sometimes its

Model/ObjectName/
and then you put ur DAO, Gateway a, Service and Listener in there

otherwise
Model/Gateway/ for gateways
Model/Listener/ for listeners
Model/Service/ for services
Model/Bean/ for beans

I like using the first approach

On Wed, Jun 11, 2008 at 4:09 PM, jlcox <jl...@goodyear.com> wrote:

Heh, mine are actually /model/listeners/[Object]Listener.cfc

--
A programmer is a device to turn coffee into code

http://www.premsweb.com/blogpro

http://www.39dn.com

[Peter J. Farrell]

My two cents...
http://greatbiztoolsllc-trac.cvsdude.com/mach-ii/wiki/FAQWhereShouldFrameworkExtensionsLive

jlcox said the following on 6/11/2008 3:09 PM:

[Matt Woodward]

The only real reason I'd suggest putting your listeners in a listeners
directory that's NOT included in your business logic packages is
because listeners aren't part of your model. That way you keep the
controllers out of your model.

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

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

[Prem Radhakrishnan]

Actually makes sense. Ill have to start changing my practices :)

[jlcox]

It's also possibly a matter of application size. If you only have a
few objects (listeners, service, DAOs, gateways) then putting them all
together in a single directory is probably fine. In my large
application, I have 26 listeners, 26 services, 22 DAOs, and 23
gateways, so splitting them into separate directories makes managing
the files easier. I think it matters not to the actual framework where
you put them.

[Peter J. Farrell]

Prem Radhakrishnan said the following on 6/11/2008 3:11 PM:

> otherwise
> Model/Gateway/ for gateways
> Model/Listener/ for listeners
> Model/Service/ for services
> Model/Bean/ for beans
>
> I like using the first approach

I agree with Prem, however instead of saying I like the first approach
versus the one above -- I'd say I disapprove of the approach above.
This this example.

You have User.cfc (bean), UserService.cfc, UserDao.cfc and
UserGateway.cfc. These are part of the "user" package thus they should
be grouped together. Otherwise, you are breaking objects into
directories based on object type (pattern/functionality of the object)
instead of the object's purpose (having to do with "user" stuff). This
is counter-intuitive as a developer would have to scan through a
"beans", "gateways", "services" and "daos" directories to see if the
User (bean) has a corresponding service, dao, gateway, etc.. Much
easier (and it makes more sense in the long run) to group by object
group instead of object type (pattern/function).

.Peter

[jlcox]

The only issue I would have with Peter's approach is that I have beans
that I use to model a particular form that don't fall cleanly into a
pariticular object group (or map one-to-one with the other objects).
For instance, as noted above, I have 22 DAOs, but 86 beans, because
some of the beans might manage many-to-many relationships or model a
form that falls across functional purposes. If I tried to put these
into folders grouped by object type, then I'd have a bunch of leftover
beans (bastard beans?) (hybrid beans?) and would have to decide where
to put them. Hunting one of them down would be more difficult that
simply looking into a /beans folder.

One could argue, probably correctly, that I have too many beans. A
virtual hill of beans. Even if I refactored everything, I suspect that
I'd still have more beans than object types, or I'd have to create
more object types to match up with the beans.

[Matt Woodward]

On Wed, Jun 11, 2008 at 4:18 PM, Peter J. Farrell <pe...@mach-ii.com> wrote:
>
> Prem Radhakrishnan said the following on 6/11/2008 3:11 PM:
>> otherwise
>> Model/Gateway/ for gateways
>> Model/Listener/ for listeners
>> Model/Service/ for services
>> Model/Bean/ for beans

Just to second what Peter's saying, I did MachBlog 1.0 like this, but
mostly because it was intended to be an application for people to
learn from, so I was thinking that grouping objects like this would
help. In most real-world applications you won't want to do this, and
since the whole notion of a package is really coming from Java anyway,
probably best to follow that convention (the one Peter outlined) for
both consistency of organization as well as ease of use.

[Vipul Suri]

well I would prefer doing this /listeners/[Object]Listener.cfc

Reason - "model" are the components of the applications which are consumed by machii framework (listeners) so I would like to keep them out of my concrete business logic

.it will be nice to have more inputs on my thought because I have been doing this since long.

[David R]

Hi,
 
(I just wonder if this is possible with Mach-II,)
 
Normally while running an Mach-II based web application we will be having our urls like,
 
http://www.mysite.com/index.cfm?event=login
 
Is there a way (Mach Specific... Not URL Rewriting) I can hide index.cfm occurence so that no body can determine my application is built on Coldfusion?...
 
Thanks in advance!..
 
Regards,
Dav R

---

CoolHotmail : Your crazy personality deserves a unique email identity like your...@iamcrazy.in. Choose from this and hundreds other unique email ids now Try it!

[Steve Crow]

Could you use custom MIME types?

[David R]

Hi Steve,
 
Thanks for the quick response.. Can you please explain about how to acheive it through custom MIME types?...
 
Regards,
Dav R

> Date: Wed, 11 Jun 2008 22:59:58 -0400
> From: reph...@gmail.com
> To: mach-ii-for...@googlegroups.com
> Subject: [Mach-II] Re: Is this possible with Mach-II

[Dan Wilson]

David,

You can configure ColdFusion to parse htm files as ColdFusion files. That means you can name all of your files with an htm extention and ColdFusion will parse and interpret thoses files as if they were .cfm files.

That means your link would be:  http://www.davescoolcompany.com/index.htm?event=DoSomething


or, if you wanted to get fancy, you could invent a new file extention called DML for Dave's Markup Language and set ColdFusion and your Webserver up to handle those files. The world is your oyster, my friend.



Here is a link to instructions on how to set ColdFusion up to parse .htm files

http://www.revolutionwebdesign.com/blog/index.cfm?mode=entry&entry=EF73296F-D247-9BB9-97915FE0604E7828


DW

--
"Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew."

Guillaume Apollinaire quotes

[Jim Priest]

On Thu, Jun 12, 2008 at 9:39 AM, Dan Wilson <sipa...@gmail.com> wrote:
> You can configure ColdFusion to parse htm files as ColdFusion files. That
> means you can name all of your files with an htm extention and ColdFusion
> will parse and interpret thoses files as if they were .cfm files.

>> > > Is there a way (Mach Specific... Not URL Rewriting) I can hide

>> > > index.cfm occurence so that no body can determine my application is built on
>> > > Coldfusion?...

As Dan said you can change your extension. I'm assuming you are doing
this for security?

FYI: http://www.port80software.com/support/articles/maskyourwebserver

Jim

[Kurt Wiersma]

Here is the simplest thing I could think of. Assuming index.cfm is the default template in Apache/IIS then just have all your URL look like the one below.

http://test.com/?event=login

You never have to mention index.cfm if it is the default template.

--Kurt