e, if you want
"horizontal" forms [1], your markup for each label/input looks
something like this:
Text input
Supporting help text
[1] http://twitter.github.com/bootstrap/base-css.html#forms (scroll down a bit)
--
Brian Cassidy
to put them up on github or the like for
everyone to use.
I think the takeaway here is that if you want radically customized
templates you either have to create your own rendering method which
circumvents the built-ins, or use a custom set of templates.
Hope that helps!
[1] for those of you
tself:
https://metacpan.org/module/HTML::FormFu::Role::Element::Field#container_tag
The tag's attributes:
https://metacpan.org/module/HTML::FormFu::Role::Element::Field#container_attributes
HTH,
--
Brian Cassidy (brian.cass...@gmail.com)
x27;d say things are good to go for an incremental release (less
the minor details like release date and such).
Cheers,
--
Brian Cassidy (brian.cass...@gmail.com)
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
official release is cut.
Hope that helps,
--
Brian Cassidy (brian.cass...@gmail.com)
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
see the failures in the CPAN Testers reports. D'oh.
I've checked in revision 1713, which adds a 'use MRO::Compat;' before
any "use mro" statement. This should solve the issue.
Please test svn trunk.
--
Brian Cassidy (brian.cass...@gmail.com)
___
On Tue, Mar 2, 2010 at 12:07 AM, Moritz Onken wrote:
> Carl planned to move his projects to github, IIRC.
This is true, but the svn history is a bit messy.
If anyone can untangle it, I'm sure Carl would be pleased as punch (as would I).
--
Brian Cassidy (brian.cass...@g
$form->get_all_element({ type => 'Repeatable' })->repeat(3);
> $form->get_all_element('count')->default(3);
> $form->process;
> }
Not sure how I missed that before. *sigh*
Thanks Carl,
--
Brian Cassidy (brian.cass...@gmail.com)
___
On Mon, Mar 1, 2010 at 2:52 PM, Carl Franks wrote:
>
> I think you'll also need to set 'new_rows_max'.
Adding "new_rows_max: 3" shows no change in the rendered form.
--
Brian Cassidy (brian.cass...@gmail.com)
___
HTML-
rst: 1
model_config:
resultset: SponsorType
- type: Text
label: Name
name: name
--
Brian Cassidy (brian.cass...@gmail.com)
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
9/HTML/FormFu/Localize.pm line 109.
> at
> /usr/local/lib/perl5/site_perl/5.8.9/Catalyst/Controller/HTML/FormFu/Action/FormConfig.pm
> line 42
> at
> /usr/local/lib/perl5/site_perl/5.8.9/Catalyst/Controller/HTML/FormFu/Action/FormConfig.pm
> line 42"
Hrmm, try removing &qu
2010/1/29 Gabor HALASZ :
> I tried localize formfu with catalyst::plugin::I18N, but I have no luck.
Can you paste your form config? Remember to use "label_loc" instead of
just "label".
--
Brian Cassidy (brian.cass...@gmail.com)
the requirement to 0.18.
I've checked this in as SVN revision 1667.
Cheers,
--
Brian Cassidy (brian.cass...@gmail.com)
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
On Sun, Jan 10, 2010 at 5:25 AM, Ansgar Burchardt wrote:
> when updating the Debian package for HTML-FormFu, lintian (one of
> Debian's QA tools) pointed out several spelling errors in the
> documentation. The attached patch should fix these.
Applied as SVN revision 1666. Than
On Mon, Jan 4, 2010 at 9:07 AM, Oskari 'Okko' Ojala
wrote:
> Is this a 2010 bug as 2009 doesn't appear in the options anymore?
>
> t/elements/date_undef.t 1/2
I've committed a fix for this as svn revision 1661 [1]. Thanks!
t wrap %n in single quote: '%n' -- that'll make YAML::XS happy.
--
Brian Cassidy (brian.cass...@gmail.com)
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
/perl/5.10.0/HTML/FormFu/ObjectUtil.pm line 502
Turns out the XML loader was assuming everything it got back was a
hashref. Obviously, in this case, it was not.
I've added a test for this, and shipped 0.18 to CPAN -- arriving at a
mirror near you shortly.
Please test it and let me know
Hi All,
This is just a quick follow-up to share my work-around for rendering a
large number of checkboxes.
I was able to deduce that the biggest problem was the number of TT2
INCLUDE statements that had to be processed. So, I just created a new TT
file which is a dumbed down version of the r
Carl Franks wrote:
Are you using auto_id() ?
If you are, this should already be handled for you, by adding an
incremented integer to the end of the ID.
See lib/HTML/FormFu/Element/RadioGroup.pm - sub _prepare_id()
Ah yes,
$self->auto_id( '%n_%c' );
-- should that be the default for things lik
Carl Franks wrote:
No, 'default' would be ignored (lost) during options().
Only 1 radio item's value can match the default.
It should be:
$self->options(
[ map {
{ value=> $_->id,
label=> ucfirst $_->name,
Hey All,
If someone could please refresh my memory, I'm attempting to populate a
radiogroup with options from a catalyst model, setting defaults is an
entry is in the stash.
It shows the options okay, but it's not setting the default properly.
I've examined $self->_options to see what comes
Hey Gang,
I was just playing around with the Radiogroup element, and i noticed the
default rendering sets the same id for each option. Naturally this is
invalid html. Traditionally i've done value="$value" id="${field}_${value}" /> for="${field}_${value}">... because the value is usually a
num
Carl Franks wrote:
On 22/09/2007, Mario Minati <[EMAIL PROTECTED]> wrote:
I just put an update on SVN.
Yes, this is a "slight issue" ;)
I've pushed a new cpan release out with the fix - it should be
available within hours.
Thanks Mario && Carl!
-Brian
Hey All,
I'm trying to speed up my form rendering -- I have a page with about
1200 checkbox + label pairs that I'm trying to display and it's taking
about 15 seconds with TT2 before the page shows up.
I thought I might try Template::Allow to see if it improves anything.
However, if i set
C
This is a bug report/warning to those using DBIx-Class-HTML-FormFu. /DO
NOT/ name any element in your page "delete" if you plan on using
$obj->fill_formfu_values( $form );
The component checks if $obj->can( $field ) then calls $obj->$field. So,
in this case, "delete" is legit and gets called.
Hey All,
This thread kind of got warnocked. Perhaps a re-post will help? :)
-Brian
Brian Cassidy wrote:
I decided to start with a simple auto-complete element. I can envision
the yaml file looking something like this in it's simplest form:
- name: foo
type: Prototype::Autocomplete
Howdy,
I was just running the latest test suite and it seems the circular ref
test throws some warnings:
t/bugs/circular_reference..Use of uninitialized
value in string eq at
/home/bricas/tmp/HTML-FormFu/blib/lib/HTML/FormFu/Element/Checkbox.pm
line 39.
Use of uninitiali
Carl Franks wrote:
The following modules have been uploaded to pause.perl.org, all at
version 0.01001
HTML-FormFu
HTML-FormFu-Imager
DBIx-Class-HTML-FormFu
Catalyst-Controller-HTML-FormFu
They should be available on http://search.cpan.org within 24 hours.
Sweet! fireartist++
Carl Franks wrote:
...but then on second thought, I decided it was a quite reasonable
request to support without having to customise your templates.
So now if you do $field->container_tag(undef);
- or "container_tag: ~" in yaml -
it'll skip the span tag.
fireartist++
Container tags can be han
Hi,
I've noticed Carl's Dojo-based widgets in the svn repository, and since
i've been doing some work with formfu and prototype ( + scriptaculous),
i thought it might be nice to have something similar for that combination.
I hope this thread will answer some questions i have about making cust
Carl Franks wrote:
Sigh, I just didn't want to mess people about by renaming all the
Element files to CamelCase - when I did the exact opposite 5 months
ago.
That's really the only reason I suggested such a complicated solution.
And I feel the current inconsistency has the potential to cause
conf
Carl Franks wrote:
I'm not entirely happy with all element filenames being lowercase, and
everything else being CamelCaps.
What I think would be better, would be to have all files under:
Elements/
Deflators/
Filters/
Constraints/
Inflators/
Validators/
Transformers/
to be low
Hi Carl,
I'm not sure why this works on my ubuntu box and not the windows box,
but i get an error (Can't call method refaddr without a package or
object reference) in two spots:
HTML/FormFu.pm
HTML/FormFu/Render/base.pm
Attached is a patch to fix that...
-Brian
=== lib/HTML/FormFu/Render/ba
Carl Franks wrote:
Ok, I've now added 'fallback' to all overloads.
I've also changed that particular line in HTML/FormFu.pm to a
defined() check, rather than truth.
Great -- I've yet to re-produce the problem once I updated to the latest
svn revision.
-Brian
__
Hey all,
I'm just doing some manual form testing by submitting a form and then
reloading the page (thus re-POST-ing the params) as i make changes.
However, often times, on first reload i get this:
Operation "bool": no method found, argument in overloaded package
HTML::FormFu::Element::text a
Carl Franks wrote:
I propose changing the key to the format: "form_${processor}_${type}"
+1
That seems like a sane default.
-Brian
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-for
Carl Franks wrote:
There's 1 thing I don't like that I've not brought up before - it's
the mismatch between the Catalyst controller being called
'HTML::FormFu' and the DBIx::Class plugin being called 'FormFu'.
I'd rather rename "DBIx::Class::FormFu" to "DBIx::Class::HTML::FormFu".
Would this caus
Hi Carl,
Not to be a total pain in the posterior, but I was just wondering about
the status of some pending CPAN releases. Most importantly, a non-dev
release of HTML-FormFu.
Another dev release is fine, though it's been dev for one and a half
months now :). Further to that, the Catalyst con
Carl Franks wrote:
On 20/07/07, kewei xiao <[EMAIL PROTECTED]> wrote:
I was at the version before you did change on "legend_loc()", after you
did changes, I checked out the latest version and updated. That's when
I couldn't see any error message.
Did you get anywhere with this?
I took a loo
Carl Franks wrote:
Yup, there's been several calls for that in the past week or two, so
I've just uploaded a dev release to pause - version 0.01000_01
(adopting the dbix-class numbering scheme) - so it should be on cpan
very soon.
Thanks! fireartist++
-Brian
__
Hey All,
A common theme we're running into is providing select boxes, and
(radio|checkbox) groups with data stored in the database.
Select boxes seem to be pretty easy
package MyApp::Form::Element::Thingy;
use base qw( HTML::FormFu::Element::select );
sub new {
my $self = shift->SUPER::
Hey All,
I was lucky enough to be able to get to YAPC::NA this year. One of my
favorite questions to ask people was "What do you use for form
handling?" Naturally, there we are variety of responses: FormBuilder,
HTML::Widget, FillInForm, "none of the above" :)
I mentioned FormFu to everyone
Hey Carl,
I know this was asked last month, but I'd like to throw the question out
there again: Any chance we could get a CPAN release of FormFu? Even a
dev release would be much appreciated.
Cheers,
-Brian
___
HTML-FormFu mailing list
HTML-FormFu
Brian Cassidy wrote:
Worked like a charm. Thanks Carl!
Sorry, that's not entirely true -- it seems to put an empty name
attribute in there instead. Any way to disable that?
-Brian
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
Carl Franks wrote:
- type: submit
default: Search
retain_default: 1
Worked like a charm. Thanks Carl!
-Brian
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
Hey Gang,
I must be doing something incorrect, but here's what I'm trying to
accomplish:
Typically i make submit buttons like this:
in the YAML config that gets translated to
- type: submit
value: Search
However, if something is incorrect in the rest of the form, when it gets
regenerat
Carl Franks wrote:
I've been getting the column info via:
MyApp::Schema->resultset('Table')->result_source->column_info;
I may be missing something, but I can't see any way of getting it
starting with 'MyApp::Schema::Table'.
MyApp::Schema::Table->result_source; gives a fatal error.
MyApp::Schem
Carl Franks wrote:
I've added an experimental new method - constraints_from_dbic() -
which I'd like feedback on.
Is this the right way to approach getting auto-constraints for
database columns, and is the interface any good?
Just off the top of my head, could you not also provide this sort of
48 matches
Mail list logo
