Masterview devel - Aug 2006 - Why :additional_directive_paths option for renderer?

I''m trying to work out the DirectiveInfo metadata scheme and namespace
support and have an old question to bring back up:  what''s the point of
providing option for  :additional_directive_paths in the Renderer?

Given that directive load paths can be controlled through the config
settings, do we need to allow for per-invocation option of specifying
additional load paths?  I''d rather have this all under the control of
the
DirectiveRegistry loader if it''s sufficient to have a single app-wide
directive context.

For directive namespace specifications, I''m thinking there''s a
range of
possible points at which one might do this:

- declaration in the directive implementation class

- declaration in the load path directory (e.g., a config file in the
directives dir with a spec for the namespace name of the directives loaded
from this directory)

- declaration in the load path config entry, e.g., allow [dirName,
namespaceName] tuple to be appended to the directive_load_paths as well as a
simple dirName as done currently

The first flavor is done by the supplier; the second could be done by either
a supplier or a consumer (directive developer zips up a directory with some
directives + the namespace spec; the developer using these directives in
their app could add/change the directory spec file as they wish); the third
is strictly in the domain of the consumer, this is part of configuring the
usage context for their app.

Also need to allow override in the app context so that directive namespace
collisions can be resolved in a client app if the two providers create
directives with the same name.

??TBD: do we need a per-document mechanism for controlling namespaces?
That''s provided for in the XML namespace architecture via the xmlns
declaration which allows you to say "I''m going to use the
following
namespace prefix to reference elements from some namespace within this
document".  But it would be simpler if we could punt on that and for
masterview directives just assert that you''re going to establish the
namespace names once and for all via the config settings for your entire
application.

~ Deb

If I remember correctly I just wanted there to be a way for users to
configure additional folders to load their directives from. One use
would be that if you have a bunch of custom directives that you want
to share across all your apps, then you could put them in a shared
folder somewhere and add this directory to the
:additional_directive_paths in addition to any custom add directory.

Not related, but a consideration to note, I wanted to allow users to
be able to require in gems that contain directives from us or other
users providing another mechanism which might come in handy for
sharing and distribution. We could have directive packs in the form of
a gem to do specific things.

So as long as your directory registry mechanism allows the user to
load custom user app specific and site wide shared directives as well
as still allowing standard require''s then I am fine with however you
want to refactor or cleanup.

Jeff


On 8/3/06, Deb Lewis <djlewis at acm.org> wrote:
> I''m trying to work out the DirectiveInfo metadata scheme and
namespace
> support and have an old question to bring back up:  what''s the
point of
> providing option for  :additional_directive_paths in the Renderer?
>
> Given that directive load paths can be controlled through the config
> settings, do we need to allow for per-invocation option of specifying
> additional load paths?  I''d rather have this all under the control
of the
> DirectiveRegistry loader if it''s sufficient to have a single
app-wide
> directive context.
>
> For directive namespace specifications, I''m thinking
there''s a range of
> possible points at which one might do this:
>
> - declaration in the directive implementation class
>
> - declaration in the load path directory (e.g., a config file in the
> directives dir with a spec for the namespace name of the directives loaded
> from this directory)
>
> - declaration in the load path config entry, e.g., allow [dirName,
> namespaceName] tuple to be appended to the directive_load_paths as well as
a
> simple dirName as done currently
>
> The first flavor is done by the supplier; the second could be done by
either
> a supplier or a consumer (directive developer zips up a directory with some
> directives + the namespace spec; the developer using these directives in
> their app could add/change the directory spec file as they wish); the third
> is strictly in the domain of the consumer, this is part of configuring the
> usage context for their app.
>
> Also need to allow override in the app context so that directive namespace
> collisions can be resolved in a client app if the two providers create
> directives with the same name.
>
> ??TBD: do we need a per-document mechanism for controlling namespaces?
> That''s provided for in the XML namespace architecture via the
xmlns
> declaration which allows you to say "I''m going to use the
following
> namespace prefix to reference elements from some namespace within this
> document".  But it would be simpler if we could punt on that and for
> masterview directives just assert that you''re going to establish
the
> namespace names once and for all via the config settings for your entire
> application.
>
> ~ Deb
>
> _______________________________________________
> Masterview-devel mailing list
> Masterview-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-devel
>