Re: Module::Starter released
Andy Lester wrote: I've just released Module::Starter 0.02, meant as a replacement for h2xs. I just reinstalled Debian on my laptop with the default perl (5.6.1). The following are the modules required and requested for Module::Starter and its dependents. Not complaining or making any judgement, just thought it interesting. Archive-Tar-1.08 Devel-CoreStack-1.3 Devel-Symdump-2.03 ExtUtils-CBuilder-0.02 ExtUtils-ParseXS-2.08 Module-Build-0.24 Pod-Coverage-0.13 Pod-Escapes-1.03 Pod-Simple-2.05 Test-Builder-Tester-0.09 Test-Harness-2.40 Test-Pod-1.12 Test-Pod-Coverage-0.08 Test-Simple-0.47 YAML-0.35
Font::FNT
Hi, I'm about to release the module Font::FNT to load, manipulate and save Windows raster fonts (.FNT files). The following methods will be available: load : creates a Font::FNT instance from a .FNT file save : saves a Font::FNT instance into a .FNT file save_yaml : saves a Font::FNT instance into a notepadable format (YAML) load_yaml : creates a Font::FNT instance from a YAML file save_pbm : saves a Font::FNT instance into a portable bitmap (for preview purposes) Is this namespace ok? Steffen
New Wrapper API for Data::FormValidator
I have written a wrapper API around Data::FormValidator and it is
getting close to being sharable.
The module basically provides an object oriented API to add form
elements dynamically, and wraps the output of a validator object from
your module.
A sample of the code to make a form looks like this:
$form-add_element( category_id, { required = 1 } );
$form-add_element( name, { required = 1, errmsg = 'Please fill
in a name for this category' } );
$form-add_element( description, {} );
$form-add_element( help_text, {} );
$form-add_element( sort_position, { required = 1, constraints
= qr/^\d+$/, invmsg = The sort position has to be a number. } );
$form-add_element( visible, { required = 0, value = 0,
constraints = qr/^\d+$/, invmsg = The sort position has to be a
number. } );
then, each element can be accessed like this:
$form-param(category_id); # the current value
$form-message(category_id); # the error message or invalid message,
depending on if
# something is missing or invalid.
Basically, this will construct a profile for D::FV to use, but still
allow easy access to the objects in the form in another part of an
application.
I am looking for naming ideas. I had initially thought of
Data::FormValidator::API, but it lacks a certain pizazz. ;)
Any thoughts? Any interest?
And hello! This is my first post to the group.
Thanks!
-jason scott gessner
[EMAIL PROTECTED]
Re: New Wrapper API for Data::FormValidator
On Tue, Apr 06, 2004 at 01:38:17PM -0500, jason scott gessner wrote: I have written a wrapper API around Data::FormValidator and it is getting close to being sharable. I think I can summarize the primary difference between this interface and the current one. With the current one, you define your validation profile with concepts like these are all the constraints that will be applied and these are all required fields, and so forth. This new API is based around fields instead. So you have concepts like this field is required or this field as a particular constraint. That clarification doesn't lead me to great name though. Here are some which seem to have right meaning, but I'm don't really like them anyway. Data::FormValidator::FieldBased Data::FormValidator::ElementAPI Data::FormValidator::Elemental Out of those, I like Elemental the best. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
