Menu
▾
▴
Re: [Modus-devs] Re: New Code Posted
|
From: Jeremy F. <jfi...@ma...> - 2002-11-15 06:54:20
|
Nathan - there's a lot in there so I'll try to address each of the =
issues individually.
Naming conventions for contentObjects: with the xml format you actually =
can use a name like org.bacfug.pressrelease. The simple name was used to =
simplify typing, but using the fully qualified name is one way around =
the application-scoped cfc library.
Not using cfapplication: please explain what the issue is here. In what =
way would this hamper a developer by making it a requirement? Using the =
application name seems to be the cleanest way to provide distinct =
containers for multiple Modus apps on the same server.
One contentObject, one persister: yes, actually, the current set up =
creates a distinct set of components for each contentObject. When I was =
referring to the application-level setting of components I meant that =
certain components, like the facade and validator, would be the same for =
all contentObjects. Each contentObject still gets its own distinct =
instantiation - again, this is still being worked out so I'm sorry if =
this wasn't clear. When you get a chance, run the app and do a dump of =
server.modus - you'll see all of the pieces layed out.
Extending contentObjects: currently the registry is not set up to handle =
this, but there's nothing preventing it. You could add an extends =
attribute to the descriptor and have the registry figure out which =
properties needed to be pulled from the parent. Quite simple to =
implement actually, so I'll give that a shot when I get some of the =
other things working.
Scope and namespace for Modus API: this is a biggy, as it's the only =
real thing users will have to worry about. Here are the contenders:
a. get("pressrelease")
b. modus.get("pressrelease")
c. server.modus.get("pressrelease")
d. server.modus.get("org.bacfug.pressrelease")
Obviously A and B would not be available within custom tags. I'm willing =
to live with that, argument already being made that custom tag =
developers are used to handling scope issues. While D is certainly a =
possibility, it really only makes sense if we need to avoid using =
cfapplication - I do think it would make code rather "onerous" to read. =
Right now I vote for the mix of B and C - maybe I'm not worked up over =
the "inconsistency" because I don't really use custom tags for display. =
Anyone is free to use C exclusively - there could even be a boolean in =
modus_settings to turn the shorthand on or off. None of this is set in =
stone, and it's proven simple to change, so let's not get too hung up =
over it. When the whole framework is clearer I think it will be easier =
to make a decision.
By the way, I've found the same loss of pageContext in server-scoped =
cfcs. I didn't think was an issue, but it seems to be - Sean?
That is one of the reasons I would propose that things like a =
persister are tied to a contentObject, not to an application. I think =
that org.bacfug.pressRelease vs org.firsenbaum.pressRelease is still a =
better way to do it than simply "pressRelease" -- IMO Modus should not =
require CFAPPLICATION to run at all. I think it's probably OK that =
org.bacfug.pressRelease has a single persister, no? I guess that with =
your setup you won't be able to extend an existing type. In the stuff I =
was working on I had succesfully extended modustest.pressRelease with =
modustest.specialPressRelease -- which had all the same "properties" of =
the pressRelease and then added some (and could override some too). Can =
you see doing that with the setup you now have? It would be a "good =
thing" I think (??).
Custom tag developers are indeed used to scope issues -- this is why =
many applications now have something like application.lib.someUDF() or =
request.lib.someUDF() -- so they can be used in custom tags. =
Personally, if it ends up being server.modus.get() I will always use =
that rather than setting modus =3D server.modus. Again, I think it =
would be good if all Modus code looks basically like all other Modus =
code, so I would encourage a convention that works both inside of custom =
tags AND in "normal" templates. The server or request scope are better =
than the application scope because they don't require CFAPPLICATION and =
they get around the nasty issue of CFC's losing the proper page context.
I think if a developer wants to build a way to make =
org.bacfug.pressRelease into "pressRelease" for the sake of their own =
application that is fine. I could also see building some kind of =
service that does this. Do you think it would be too onerous to require =
explicit names for object types?
- n
-----Original Message-----
From: mod...@li... =
[mailto:mod...@li...]On Behalf Of Jeremy =
Firsenbaum
Sent: Thursday, November 14, 2002 2:37 PM
To: mod...@li...
Subject: Re: [Modus-devs] Re: New Code Posted
Well, I just confirmed this. The included UDFs are not available to =
custom tags. This leaves us with a big decision.
One of Nathan's concerns when discussing the UDF was approach was =
defining a namespace for Modus. I think this is a more powerful argument =
for the static CFC library than custom tag access. Seems to me that =
custom tag developers should be used to scope issues as these were the =
first real way to do encapsulation with CF.=20
I really prefer the modus prefix on the functions as it defines a =
clear namespace for the API. One of the things I'm working on now is an =
application-scope cfc to hold the API functions. This is similar to the =
example I gave earlier where server.modus.udflib is referenced as modus =
in Application.cfm. Custom tag developers would need to use the full =
path in this case.
As for many applications not using the cfapplication tag, that's =
news to me. The whole framework depends on the application name to allow =
various Modus apps to be run concurrently on the same server without =
name conflicts. Look at the way the registry constructs the components:
server.modus[appName].persister[componentName];
The UDF lib uses the applicationname to find the appropriate facade =
to call. This is why I'm looking into making the UDF lib a static =
application CFC. The loss of pageContext bug prevents CFCs from =
accessing the application scope. Each application would have its own =
static lib that maintains the applicationname in the instance scope. =
Thus normal page calls would look like modus.get() and custom tags would =
need to do application.modus.udflib.get(), or whatever the static lib =
winds up being called.=20
If there's another way of doing this and still preventing name =
conflicts (my pressrelease and your pressrelease on the same server) =
then shout it out. This is crucial to the way Modus gets used so we =
should take the time to get it right.
-Jeremy
----- Original Message -----=20
From: Nathan Dintenfass=20
To: mod...@li...=20
Sent: Thursday, November 14, 2002 4:25 PM
Subject: RE: [Modus-devs] Re: New Code Posted
> > Given that we're moving to "Modus as service" as our model,
> > server.modus makes the most sense to me (why copy it all into =
the
> > request scope, after all?). Make sense?
>
> Yes, although I still prefer the UDF approach :)
Well, but you still need to put it in the server or request or =
application
(or session) scope to make it available to custom tags. I think
server.modus is just a struct, not a CFC instance. So, putting =
UDF's in
that struct should not be a big deal. This assumes the user won't =
do
something stupid like structClear(server.modus), but I suppose =
there's
little to be done about that.
- n
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing =
your web site with SSL, click here to get a FREE TRIAL of a Thawte =
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Modus-devs mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/modus-devs |
