Re: [Modus-devs] Re: New Code Posted

[Jeremy F. <jfi...@ma...>]

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=20
  your web site with SSL, click here to get a FREE TRIAL of a Thawte=20
  Server Certificate: http://www.gothawte.com/rd524.html
  _______________________________________________
  Modus-devs mailing list
  Mod...@li...
  https://lists.sourceforge.net/lists/listinfo/modus-devs