|
|
Posted by Toby A Inkster on 04/08/07 13:32
Tyno Gendo wrote:
> should i rely on module users naming their form inputs specifically to
> their module, or should my app (when register the modules) supply a
> module with a unique 'ident' that the module writer should then check
> for in their code and all for in their forms etc.
The latter route sounds like a good idea. For my current project though, I
went the former route, though in my API document, I've described a naming
convention (similar to the naming convention used by Java packages) to
avoid naming collisions between different modules.
The convention is like this: say I'm writing a module that does "foo" for
the package, and I own the domain name "tobyinkster.co.uk", then I'd name
my module:
uk_co_tobyinkster_foo
If my module needed to create, say, form input fields, it would make sure
they used "uk_co_tobyinkster_foo" as a prefix for the field names. If it
wanted to generate some HTML output using some "class" or "id" attributes,
then it would similarly prefix them.
If a module user didn't own their own domain name, they could simply use
their e-mail address:
com_hotmail_at_joebloggs_foo
Although you do end up with some fairly ugly-looking module names, this is
a pretty sure-fire way to avoid naming collisions. Because of the ugly
names, in my plugin registration function, I do allow plugin authors to
provide a "friendly" name for their plugin, which is displayed anywhere a
user is likely to see it. I also allow them to provide a link, the author's
name, some version information and so on.
--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux
* = I'm getting there!
Navigation:
[Reply to this message]
|