> I will step up to write this code. (if it is what I think it is)
> I have responded to the message by beginning a requirements document.
>
> http://www.officevision.com/pub/HTML-Widget/
>
> Please read it and send me any comments.
> The following are the questions I need advice on in order to proceed.
>
> * What CPAN package namespace should I use?
> I studied the existing packages, and what we are trying to do looks
> like it fits under the existing top level package HTML.
> I propose to take the space "HTML::Widget" (see package layout in
> design doc). Gunther suggested the top-level "Widget" name space.
> I was under the impression that we should stay away from creating
> new top-level entries at CPAN unless there was really *nothing*
> similar. Confusingly, there is already an HTML::Widgets. Thoughts?
First, I think it's not important to get started with. I think we can
start with Widget:: given that the code is not strongly tied to HTML. In
fact think of the email templates where you want the widget to do the
right thing when a respond is sent via email and not HTML (not talking
about certain companies who want the emails to be sent in HTML).
Once we have more code written, we can talk to the CPAN gods (Andreas
Koenig and alike) and particularly comp.languages.perl.modules news group
which is supposed to deal with it. If the class is well abstracted I don't
think there will be a resistance to start a new namespace.
But I think that a pure intention is not good enough to convince people. A
working code always makes things easier. If the choice of the namespace
will be proven to be wrong we can easily s/Widget::/Rocket::/ and do the
filename renaming. So it's a non-issue I think.
> * What CPAN packages should I begin with and build upon?
> CGI and Apache::Request were mentioned. I figure I will use these.
> HTML::StickyWidgets was also mentioned. Do you mean HTML::StickyForms?
> Are there others I should build dependencies on?
I think we are talking about thing that should be very abstract, so you
probably can use whatever you feel comfortable with, probably
CGI.pm/Apache::Request on one side and CGI.pm/HTML::StickyForms on the
other side to start with. But we have to make sure that other packages
will be easily plugged in. This is something that we call 'drivers' in
our extropia.com ADT, you need only to write a driver for a particular
service/module to make use of this service/module, without changing your
applications. Well you know that already from DBI:: world.
Then later on someone will come up with a plugin for TT and other
templating systems...
> * Should I begin immediately with a new Sourceforge project? another way?
> The codebase I will begin with is in CVS on my local server.
> Perhaps I should just continue that way and post versions to CPAN
> for distribution. However, we may have email traffic for the project
> that exceeds the general interests of the modperl list. Thoughts?
> I would need to get enough responses from people who would join that
> Sourceforge mailing list before it would be worth it to go do that.
sourceforge is a good idea as it gives you a public cvs and mailing lists.
(bug tracking and etc). I don't think that things should be placed on CPAN
yet. Once you have a working version, that's when it should get released
on CPAN.
Of course these are only my thoughts... :) As the leader of the project
you decide how you want things to be done, and we can just try to push you
into the _right_ direction :)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
