then takes data
returned from the call and uses it to expand its internal
dispatch table.
BUGS/CAVEATS
UberText is pretty complex. There's probably bugs floating
around because I haven't even conceived of all of the possible
input errors or third party mod
On Sat, 12 Oct 2002, Leon Brocard wrote:
> Chris Josephes sent the following bits through the ether:
>
> > Given the high number of template systems out there, it is easy to
> > understand the reluctance or hesitation in adding another one to
> > CPAN.
>
> Eve
On Mon, 14 Oct 2002, Andy Wardley wrote:
> Chris Josephes wrote:
> > 2. Text::MetaText
> [...]
> > ...but it has a very limited command set with no means
> > to allow for expansion.
>
> ... and has been superceded by the Template Toolkit.
Oops. Sorry about tha
On 14 Oct 2002, William R Ward wrote:
> You overlooked HTML::Template, which I think would meet all of your
> needs. It is unfortunately buried under HTML:: but it is useful for
> all kinds of templating tasks.
HTML::Template doesn't look like it's expandable. The FAQ mentions the
possibility
On Mon, 14 Oct 2002, David Kaufman wrote:
> the way to avoid your two concerns (permissions and support) is to
> participate in the community, join the mailing list of the system you like
> best, and would want to contribute to, listen a while, and suggest your
> changes. most likely they will b
On Tue, 15 Oct 2002, Terrence Brannon wrote:
> > Chris> 2. The template language should not follow Perl syntax rules,
> > Chris> or be designed with preference towards Perl users or
> > Chris> programmers.
>
> 1. developing a good language is very difficult.
I didn't mean to necessarily infer t
On Tue, 15 Oct 2002, David Kaufman wrote:
> while this is statisfyingly powerful, and simple enough even for
> non-programmers to add, it too leads to template-as-language addiction, when
> the brain-rush resulting from the taste of power corrupts the normal,
> keep-it-simple sensibilities of the
On 15 Oct 2002, William R Ward wrote:
> For me, it's because TT allows Perl to be embedded in the template.
> That way lies madness. The advantage of a templating system is that
> you can leave the template maintenance to someone who doesn't know
> programming, and let the programmer focus on th
On Fri, 29 Nov 2002, Tommi [iso-8859-1] Mäkitalo wrote:
> Hi,
>
> I think Queue::File would be appropriate.
>
> Your primary intent is to process Queues, not Files.
>
How about Queue::Directory, since you're working with multiple files?
Queue::File might be suggestive that you're working on a sin
On Fri, 3 Jan 2003, Jay Lawrence wrote:
> I am thinking more along the line of:
>
> Business::vFile::
> VCALENDAR
> VFILE
Isn't there an XML equivelant of the vCard specification? I know Jabber
uses an XML formatted vCard for its user directory.
What if you jus
On Fri, 3 Jan 2003, Jay Lawrence wrote:
> And yeh, upon writing this it makes sense to move them up. The
> Business::vFile module remains as the base class, but I will rename the
> others to : Business::vCalendar vs. Business::vFile::vCalendar.
One good thing about "Business::vFile" would be you
On Sun, 30 Mar 2003, Ezra Cooper wrote:
> Assuming that it's OK, the other questions are:
> * Where should I put it in the namespace? I don't suppose adding a new
> top-level space "Spine" would be wise. Should I put it under HTML:: and
> have HTML::Spine, HTML::Spine::Log, etc?
I think putting i
On Sun, 18 Jan 2004, Lincoln A. Baxter wrote:
> In my case, it is a Server/Integration platform for framework. In that
> discussion (to be posted later this week maybe), I will suggest that
> instead of creating a new TLNS for the application, perhaps all such
> applications should eventually be
On Mon, 19 Jan 2004, Mark Stosberg wrote:
> I would rather CPAN be wide at the top level than have un-intuitive
> names. The author based system will also become more difficult when
> authors change hands, disappear, or there are multiple authors.
There's kind of a trade-off here. Right now, whe
On Mon, 19 Jan 2004, A. Pagaltzis wrote:
> * Chris Josephes <[EMAIL PROTECTED]> [2004-01-19 14:39]:
> > I think sooner or later, we're all going to have to bite the
> > bullet and go with Java class naming conventions, like
>
> IMO, it is of the essence tha
On Mon, 19 Jan 2004, Mark Stosberg wrote:
> And then the 1000 people who use their module can all do a find and
> replace on all places where they have referenced the the module name
> with the other authors ids.
>
The namespaces don't have to change overnight.
> And what happens when module aut
On Mon, 19 Jan 2004, Orton, Yves wrote:
> Also, the author namespaces issue is problematic in that how would you
> determine whose version is the latest, or correct or whatever.
>
Version numbering is an authorship issue. If I took over module Widget
from author XYZ, I'd probably use higher vers
On Mon, 19 Jan 2004, Daniel Staal wrote:
> Basically, adding the author's name into the name of the module just
> trades an illusion of a 'clean' TLD for my headspace. I would rather
> have a messy TLD: there are tools that can help me search and sort
> that. Perl is *supposed* to help me clean
On Tue, 18 May 2004, Michael A Nachbaur wrote:
> Since the whole framework is 100% Perl, I feel it would be worth it to publish
> it on CPAN, especially since the underlying Perl modules can be extended by
> other users. This is the kind of problem I'd like to solve with a new top
> level namespa
On Wed, 16 Jun 2004, Mark Stosberg wrote:
> Another perspective: I do see signs that the current rating system is
> helping. After receiving several negative ratings, CGI::NeedSSL has been
> pulled from CPAN.
What was the deal with this? I never used the module, I was just curious
about what hap
I'm 50/50 on this.
Just because a module name mentions "Javascript" doesn't mean it would
immediately be discounted by other developers. If people need something
to handle Tooltips, they'll use it, or at least read the pod
documentation.
Also, there are lots of other tooltip implementations out
On Wed, 16 Jun 2004, Fergal Daly wrote:
> On Wed, Jun 16, 2004 at 06:39:22PM -0300, SilvioCVdeAlmeida wrote:
> > Let's write it better:
> > 1. FORBID any module without a meaningful readme with all its (possibly
> > recursive) dependencies, its pod and any other relevant information
> > inside.
>
On Thu, 24 Jun 2004, Mark Stosberg wrote:
> > HTML::DragDrop::Javascript
> > HTML::DragAndDrop::Javascript
>
> Is there a way to implement Drag and Drop with HTML /without/ using
> JavaScript? I suspect not. Thus, I think it could be appropriate to drop
> 'Javascript' from the name
>
> > HTML::Dra
What about WWW::Service::Map???
That would seem to fit.
On Fri, 9 Jul 2004, Dave Rolsky wrote:
> On Fri, 9 Jul 2004, David Wheeler wrote:
>
> > On Jul 9, 2004, at 3:43 PM, Dave Rolsky wrote:
> >
> > > This'd be great _except_ that www.maplink.com is the website for a
> > > map/travel book compan
So, if I want to write a review of Net::SMTP, I'd do the following.
1. Use Module::Build, or ExtUtils::MakeMaker to create
Review::Net::SMTP::CHRISJ, or whatever.
2. Make sure I have my README.txt, CHANGES, and MANIFEST file.
3. Write my review in POD format, and throw in some META.yml indexing
On Thu, 22 Jul 2004, Ken Williams wrote:
> I was sort of hoping this idea would just die on its own, but now it
> looks like people are actually getting ready to do it. In my opinion
> this is a bad idea. I don't want a bunch of reviews all over CPAN
> disguising themselves as modules. I also d
How does the code check the integrity of the file? I mean, is there any
hardware/driver code thrown in here? Is it specific for systems using
SATA controllers?? That might affect namespace ideas.
I liked the File::Integrity suggestion, but I'd want to know more.
On Sun, 17 Oct 2004, Joshua Hob
On Tue, 7 Dec 2004, Christopher Hicks wrote:
> I don't care about Oracle or any of the rest. Making this work with PG
> and MySQL will solve 90% of the world's problems. I don't see why it
> couldn't be extended to include whatever parameters where necessary for
> any of the proprietary database
On Tue, 4 Jan 2005, Scott W Gifford wrote:
> The advantages of having the data on CPAN is that the entire module is
> self-sufficient and widely mirrored. It makes it much easier to
> install, and if you have a CPAN distribution on CD or in a local
> mirror, you have everything you need. The dis
On Thu, 6 Jan 2005, Scott W Gifford wrote:
> If the user has custom data, they would just install Geo::PostalCode
> and build their own database (it includes a short script to do this,
> and the process takes about 2 minutes). Geo::PostalCode::US doesn't
> replace Geo::PostalCode, but just adds a
On Thu, 6 Jan 2005, Chris Josephes wrote:
> 2. Include a "make install-data" target that will unzip the data, and then
> install it in a standard location your module will search by default.
> Would /usr/share/postal/us be a bad place? Is anyone else doing this?
As a quick
Any idea of what it would take to get a password reset on a CPAN account?
It turns out the email address I used is no longer being forwarded to my
current account anymore either.
Christopher Josephes
[EMAIL PROTECTED]
32 matches
Mail list logo
