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

[Nathan D. <na...@ch...>]

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

  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.

  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 -----
    From: Nathan Dintenfass
    To: mod...@li...
    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