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.
On Wed, Jun 11, 2008 at 4:11 PM, Prem Radhakrishnan
On Wed, Jun 11, 2008 at 4:15 PM, Matt Woodward <mpwoodw...@gmail.com> wrote:
> 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.
> On Wed, Jun 11, 2008 at 4:11 PM, Prem Radhakrishnan > <godsmustbcr...@gmail.com> wrote: > > 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
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.
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).
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.
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. -- Matt Woodward mpwoodw...@gmail.com http://www.mattwoodward.com/blog
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.
On Thu, Jun 12, 2008 at 1:41 AM, Prem Radhakrishnan <
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 _________________________________________________________________ No Harvard, No Oxford. We are here. Find out !! http://ss1.richmedia.in/recurl.asp?pid=500
> 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 > yourn...@iamcrazy.in. Choose from this and hundreds other unique email ids > now Try it!
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: rephle...@gmail.com> To: mach-ii-for-coldfusion@googlegroups.com> Subject: [Mach-II] Re: Is this possible with Mach-II> > > Could you use custom MIME types?> > > On Wed, Jun 11, 2008 at 10:12 PM, David R <dav_...@hotmail.com> wrote:> >> >> > 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> > yourn...@iamcrazy.in. Choose from this and hundreds other unique email ids> > now Try it!> > >> >> > _________________________________________________________________ Watch hottest Bollywood videos, clips, movie tailors, star interviews, songs and more on MSN videos. http://video.msn.com/?mkt=en-in
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.
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
On Wed, Jun 11, 2008 at 11:12 PM, David R <dav_...@hotmail.com> wrote: > 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: rephle...@gmail.com > > To: mach-ii-for-coldfusion@googlegroups.com > > Subject: [Mach-II] Re: Is this possible with Mach-II
> > Could you use custom MIME types?
> > On Wed, Jun 11, 2008 at 10:12 PM, David R <dav_...@hotmail.com> wrote:
> > > 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,
> > > 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 > > > yourn...@iamcrazy.in. Choose from this and hundreds other unique email > ids > > > now Try it!
-- "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."
On Thu, Jun 12, 2008 at 9:39 AM, Dan Wilson <sipac...@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?
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.
On Thu, Jun 12, 2008 at 8:47 AM, Jim Priest <pri...@thecrumb.com> wrote:
> On Thu, Jun 12, 2008 at 9:39 AM, Dan Wilson <sipac...@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?
|
