With respect to packaging, you may wish to check how it is done for comparable modules:
About the interface... what do you actually intend to expose to the perl developer? (I'm just curious, you write what you please ;)
I don't really understand the rational behind these "do the client-side as some transparent aspect of the server-side" frameworks (eg: ASP.Net, GWT), but I'll just assume it's because I lack the "enterprisey" gene.
I quite like jQuery's approach... Prototype done in a cleaner, more declarative fashion (although I hear the Prototype folks are catching up).
-David | [reply] |
The basic ideas are:
to make some of the widgets easily accessible
to make Ajax simple
to have access to some of the effects
to autogenerate anything that can be autogenerated
If developers want new widgets or added functionality, modules can be added that will improve the utility of the package.
| [reply] |
You probably want to use Module::Build. With it you can easily collect path names during initial unpacking, then install to them during install. See Gantry or Bigtop for examples. Here is a minimal example of a Build.PL:
Disclaimer: I excerpted the above from Gantry's Build.PL to give you a feel for how things look. But, I didn't test the above so it probably doesn't complile. See Gantry for the example. Bigtop actually generates Build.PL's based on Gantry::Build which facilitates doing this, if you only need to install subdirectories to one top level path. You probably want to invest in an actual module for the Module::Build subclass.
Phil | [reply]
[d/l] |