[Modus-devs] Re: New Code Posted

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

This is the beginnings of a conversation between Nathan and I about the =
revamped Modus code I posted on Sunday. Thought it would be appropriate =
to share:

  > I'm in the middle of rethinking this now. I want the ability to
  > define contentObject-level components, especially persisters.
  > But, the facade, validator and renderer are more
  > application-level. I'm thinking of renaming the facade to
  > contentobject and define these in the global settings file - that
  > way the true interface for the developer would be the
  > contentObject. The descriptors would then define content types
  > that the contentobjects can implement. So you could have a
  > pressrelease, a remotingPressrelease and a xmlPressrelease using
  > the same descriptor. This is all in progress so more to come. The
  > end goal, of course, is a blend of simplicity and flexibility. A
  > newbie should be able to edit the example app and have a running =
website.

  I absolutely agree about the newbie case.  I think it would also be =
good if
  we keep things at the contentObject level rather than the application =
level.
  That is, using different contentObjects with different =
validators/renderers
  in a single application makes some sense to me.  My question was more =
about
  the semantics of:

  <components>
    <component name=3D"persister"
  type=3D"org.bacfug.modus.persistence.simpleobjectinstance" />
    <component name=3D"validator" =
type=3D"org.bacfug.modus.validation.validator"
  />
    <component name=3D"renderer" =
type=3D"org.bacfug.modus.rendering.baserenderer"
  />
    <component name=3D"facade" =
type=3D"org.bacfug.modus.facades.webfacade" />
  </components>

  As opposed, perhaps to:

  <persister type=3D"..."/>
  <validator type=3D"..."/>
In fact I started this way, naming the components. However, I was =
looking for a way to add new component types without altering the =
registry code. In the end, I don't know if this will possible, but it's =
a nice ideal. Just write a new component, add it to the settings file =
and away we go. In any case, I'm reworking the whole descriptor =
implementation so I'll keep you updated.


  I do think the term "facade" is not particularly friendly.  I could =
even see
  it being simple "ui" -- a term that is both well known and very =
descriptive.

  >
  > 2) I am not fully comfortable with the UDF lib as is.  It creates
  > issues with using custom tags, so I would prefer to see some kind
  > of convention like server.modus.get(), or some other way that a)
  > makes the code the same inside a custom tag as outside a custom
  > tag and b) makes the API a developer uses more explicitly in a
  > Modus "namespace" of sorts.
  >
  > No problemo - this was Sean's suggestion so I thought I'd try it.
  > The UDFs are really just directing traffic to the appropriate
  > facade. This could also be implemented as a cfc. This way a
  > Application.cfm could have something like:
  >
  >      modus =3D server.modus.udflib
  >
  > so the calls would be: modus.get(id) and modus.put(object).
  >
  > Lot's of ways of doing this so when you guys get some time to dig
  > in we can figure out the best way.

  Yeah, I figured this was more proof-of-concept than it was API =
proposal.  My
  issue is that it would be great if the developer types the same thing =
inside
  a custom tag as they do outside a custom tag.  That would require =
something
  like server.modus.get() or request.modus.get() every time, though.  I
  suppose it's not crucial that it's always the same, but it would be =
nice if
  Modus code always looks like Modus code, if you get my drift.

Absolutely - it would be silly to have a split API depending upon scope =
- I also think CFC methods don't see UDFs.


  BTW, your speed numbers are very convincing!

-Jeremy