Re: Features Listing

"mikespub" <[email protected]> wrote in message
news:[email protected]
> In article <bk7a3d$a95$1-111RdWWlOxkOkXtL6OYfHgC/[email protected]>, "Jason Judge"
<[email protected]> wrote:
> >...
> >You know a bit about hooks: is is possible to provide different types of
> >hooks from a module to different modules? For example, could Autolinks
> >provide a transform hook to all modules, but a create/update GUI hook to
a
> >selected few modules? Or is it an all-hooks-or-nothing system, with the
hook
> >module deciding when it should and should not supply hook details? I'm
> >probably asking the wrong questions there - as I am not very familiar
with
> >the GUI side of hooks.
> >
> >Just something I am beginning to mull over as I see transform hooks with
> >preg-replaces pop up all over BK...
> >
> >-- JJ
>
> Hooks are an all-or-nothing business (excepting if you delete individual
> entries in the xar_hooks table). However, you could return immediately
> when some modules call one of your hook functions, and handle calls
> from other modules in a different way.

Thanks - that's what I thought, but wasn't sure.

> For example, the ratings module allows you to configure different
> rating styles depending on who's calling, the changelog module
> allows you to specify which fields to save for each module, and
> of course, dynamicdata does different things for everybody who
> calls too :-)
>
> Or you could also imagine supporting different sets of transforms
> depending on who's calling, for instance...

Yes - I was thinking, for example, of allowing different autolink types to
be linked to specific modules, and for specific themes. This would allow
different sets of autolinks to be available in a printer theme than for a
browser theme. Using dynamically-executed templates, you can now have
different link styles in different themes, for the same link, but you can't
disable whole groups of autolinks in themes for which those groups are not
relevant (except in a hacky way, by providing templates for those themes
that don't transform anything - just display #$match#).

Other examples may be the provision of complex links that bring in content
from other modules, but only available in a module that the admin maintains,
and only simple autolinks in the remaining modules in which other users
could enter content. Ideally groups of links could check the permissions of
the author of some content to determine whether they should be allowed.
Perhaps this can be done as input transforms, though that does tend to lose
some of the dynamic abilities of the link templates.

Whether that provides a fine enough level of granularity to be useful, I'm
not sure, but what is apparent is that it is possible to create autolinks
that can bring in (as well as link) content across different modules in the
site, but which you would only want admins playing with. BL widgets won't
work here as they don't operate within content - only in templates
surrounding content.

Hmm. I may just wait and see what feature requests the weekend brings in...

-- JJ