Re: [Catalyst] No database defaults with FormHandler and DBIC

[Gerda Shank]

A database row is used for defaults only if it is provided in the ‘item’
attribute. If you provide only the item_id and item_class they are used to
update the row but not for defaults.

Gerda


On Mon, Oct 31, 2016 at 12:00 PM, Martin Rehak  wrote:

> Hi,
>
> thanks much for comments.
>
> I know there are number of ways how/where to set/define defaults from app
> code
> and there is large text written about it in Catalyst documentation.
>
> What I would expect to work at least is that database default is going to
> be
> propagated into the form from the schema definition. I don't need to have
> the
> second place with explicit default definition when there is and implicit
> definition coming from db.
>
> In other words:
> $ script/reha_create.pl model DB DBIC::Schema reha::Schema create=static
> 'dbi:Pg:dbname=;host=' reha 
>
> generates
>
> =head2 capacity
>
>   data_type: 'integer'
>   default_value: 1
>   is_nullable: 1
>
> and there is the default definition successfully fetched from db. How to
> get it
> used without any override (and duplication) in the app code?
>
> Thank you very much in advance.
>
> Regards
> --
> Martin
>
> On 2016.10.31 09:23:26 +, LNATION . wrote:
> > Probs incorrect approach but it'll work
> >
> > before render => sub {
> > unless ($_[0]->field('capacity')->value) { # mayb editing
> >  $_[0]->field('capacity')->value(1);
> > }
> > }
> >
> > On Mon, Oct 31, 2016 at 8:28 AM, Marc0 
> wrote:
> >
> > > Am 31.10.2016 um 09:15 schrieb Marc0:
> > > > Am 31.10.2016 um 08:57 schrieb Martin Rehak:
> > > >> has_field 'capacity' => (type => 'PosInteger',
> > > >> #default => '1',
> > > >> label => 'Kapacita');
> > > >
> > > > maybe add a "lazy => 1" to your commented "default => '1'"?
> > > >
> > > > has_field q(capacity) => (
> > > > type=> q(PosInteger),
> > > > lazy=> 1,
> > > > default => q(1),
> > > > label   => q(Kapacita),
> > > > );
> > >
> > > maybe "capacity" is explicitely set to undef, you could try an "around"
> > > method modifier to check for a defined value:
> > >
> > > has_field q(capacity) => (
> > > is  => q(ro),   # just guessing
> > > type=> q(PosInteger),
> > > lazy=> 1,
> > > default => q(1),
> > > label   => q(Kapacita),
> > > writer  => q(_set_default_capacity),
> > > );
> > >
> > > # untested, but according to Moose::Manual::MethodModifiers
> > > around q(has_field) => sub {
> > > my $orig = shift;
> > > my $self = shift;
> > >
> > > # check for definedness and set to default value if
> > > # not defined (NULL)
> > > $self->_set_default_capacity(1)
> > > unless defined $self->$orig();
> > >
> > > return $self->$orig();
> > > };
> > >
> > > Regards
> > > --
> > > Marc0
> > >
> > > ___
> > > List: Catalyst@lists.scsys.co.uk
> > > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> > > Searchable archive: http://www.mail-archive.com/
> > > catalyst@lists.scsys.co.uk/
> > > Dev site: http://dev.catalyst.perl.org/
> > >
>
> > ___
> > List: Catalyst@lists.scsys.co.uk
> > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> > Searchable archive: http://www.mail-archive.com/
> catalyst@lists.scsys.co.uk/
> > Dev site: http://dev.catalyst.perl.org/
>
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/
> catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] HTML::FormHandler and the Catalyst stash

[Gerda Shank]

On Wed, Jan 16, 2013 at 5:39 AM, Jacinta jar...@perltraining.com.au wrote:


 I have looked through most of the documentation for HTML::FormHandler and
 I can't find anything that actually documents process() (it returns 1 on
 success) and I don't know the Catalyst stash well enough.  Is this
 information hiding therein or do I need to create a method to get the last
 insert id?


The primary key of the created row is available in $form-item-book_id.

Gerda Shank
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: HTML::FormHandler help!

[Gerda Shank]

On 3/6/12 12:13 PM, Sungsam Gong wrote:

Dear Gerda,

Thanks for making HTML::FormHandler, which I found very useful.

I was trying to make a simple registration page using
HTML::FormHandler, but couldn't make it through.
The form itself looks OK, but after clicking the submit button, I got
an error message which I dumped below:


Sungsam:

You've left off a lot of the pertinent information, including your form 
and the result source class. This:  Nectar::WebV2::Model::NECTAR::User 
doesn't look exactly like a DBIC row object, just from the name. And 
since the update code is failing, there's got to be something wrong in 
the relationship to DBIC. The update is done in the 'update_model' sub. 
You might want to see what's in the $form-value that's supposed to be 
passed to DBIx::Class::ResultSet::RecursiveUpdate. That interface is 
pretty simple. You can take the value hashref and pass it to 
RecursiveUpdate yourself, which might be easier to debug.


Gerda




___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Best form library?

[Gerda Shank]

On 3/7/11 5:18 AM, Erez Schatz wrote:

IIRC, there were issues with labels on controls. We wanted no label on
a button, and had to override the button render method. There were
some other stuff in which the way we wanted the form to look didn't
fit the way H::FH thought a form should look, resulting in overriding
the rendering methods and lots of crufty code.

Setting the widget wrapper to 'None' for the form or the field, or the 
'no_render_label' flag on a field, or setting the label in a field to '' 
will all suppress rendering the label. Or you could use templates and 
not use the rendering at all, or just render the bare input fields.


I'm not personally a fan of automatic rendering. It's pretty impossible 
to come up with a standard way of rendering that everybody is going to 
like, and adding tons of flags to handle every option is also a horrible 
idea. Automatic rendering is good for prototyping, to make sure the 
thing is working to start with. And it's good if you have a really 
standard presentation where it's worth it to come up with a set of 
widgets that fit your requirements.


Gerda


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Formhandler and Auth

[Gerda Shank]

On 3/4/11 8:23 AM, Eric Berg wrote:
I'm trying to do some progressive engagement by allowing one of my 
forms to be filled out before a user is required to log in, but once 
the form is filled, I need them to log in so that I can get the user 
ID, which is part of the record for that form's row in my db.
So after the form is submitted, you want to save the form contents 
somehow, then present a login form, then after the user logs in, save it 
to the database?


Is the part you're not sure of how/where to save the form contents? 
There are the usual options for preserving data across several requests, 
i.e. stash, database, etc.


Then you'd have to decide how you want to save the data. You *could* use 
FormHandler to do that, but if you have an already validated set of 
data, it might be simpler to just save it to the database yourself.


I'm not quite sure if I addressed the particular issues you were having; 
if not, please clarify :)


Gerda


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Feedback requested on HTML::FormHandler's new widget system

[Gerda Shank]

A new widget system for HTML::FormHandler is currently under 
development, and it would be nice to get feedback from those who might 
be interested in it before putting it out in a release.


It's currently in the HTML::FormHandler repository on github:

http://github.com/gshank/html-formhandler/tree/master

I've copied the current version of HTML::FormHandler::Manual::Rendering 
at the end of this email.


Please respond offlist or on #formhandler.

Thanks,
Gerda Shank

=

=head1 NAME

HTML::FormHandler::Manual::Rendering

=head1 SYNOPSIS

HFH has a number of different rendering methods.

  1. Handcoded html with no assist from HFH at all
  2. Use templates and the field 'widget' to determine the template snippet
  3. Use a rendering role in your form class, like Render::Simple

and now:

  4. Automatically installed rendering widgets using a combination of
 rendering roles, which can easily be customized by the user.

=head1 Rendering with Widgets

All FormHandler widgets are Moose roles.
Default widget roles are installed into HTML::FormHandler::Widget. They 
include
widgets for the fields in the distribution. Each field can render itself 
with
C $field-render . The widget rendering roles are applied at build 
time in

each field object.

The name space used to look for the widget roles can be specified on a 
form or

field basis by setting 'widget_name_space' to a scalar name space, like:

  has '+widget_name_space' = ( default = 'MyApp::Form::Widget' );

or to an arrayref of name spaces:

  has '+widget_name_space' = ( default = sub { ['MyApp::Form::Submit',
  'MyApp::Form::Widget' ]);

The HTML::FormHandler::Widget name space is always searched as the last 
name space.
This means that you can set up an application or form specific set of 
widgets.


Widgets in a widget directory (specified in widget_name_space) are 
located in either

a 'Field', 'Wrapper', or 'Form' subdirectory.

The form's rendering role is looked for in the widget name space plus 
'Form'. The
default form rendering roles are in HTML::FormHandler::Widget::Form. The 
form

widget is specified in the form with 'widget_form'.

  package MyApp::Form;
  
  has '+widget_form' = ( widget_form = 'Simple' );
  ...

The 'wrapper' for field rendering can also be specified with 
'widget_wrapper'.

The widget specified will be looked for in the widget directories' 'Wrapper'
subdirectory. It contains a 'wrap_field' method which is called from the 
Field
widgets.  The wrap_field method takes the basic rendered field (passed 
from the
field widget) and wraps it with HTML. The defaults provided are 'Div' 
and 'Table'.

You can specify a wrapper class for all the fields in the form by setting
'widget_wrapper' in the form class, or you can set them individually by 
setting

'widget_wrapper' on individual fields.

  has 'some_field' = ( widget_wrapper = 'MyWrapper' );

The 'widget' attribute is set to a default in FormHandler fields, or you 
can

set it to a different widget in your field declarations.

  has 'another_field' = ( widget = 'MyWidget', widget_wrapper = 
'MyWrapper' );


Can be set in the form:

  widget_name_space
  widget_wrapper
  widget_form

Can be set in the field:

  widget_name_space
  widget_wrapper
  widget

The widget_name_space and widget_wrapper will be copied into the fields 
from the

form if they are not already defined.

By default, a form will use the Form::Simple and Wrapper::Div widgets. 
If you
want to use the table format you can change the 'widget_form' and 
'widget_wrapper'

attributes in the form, or do it on new:

  my $form = MyApp::Form-new( widget_form = 'Table', widget_wrapper 
= 'Table' );


The form widgets will not be applied if a 'render' method already exists 
in the form,
such as is the case when you've done a 'with' for 
LHTML::FormHandler::Render::Simple.


=head1 Customized Widgets

You can create custom widgets for your complete application or on a 
per-form basis.

One possible layout for your widgets;

  lib/MyApp/Form
  lib/MyApp/Form/Widget/Form
  lib/MyApp/Form/Widget/Field (contains MyWidget.pm)
  lib/MyApp/Form/Widget/Wrapper

Create custom widgets and put them in the respective directories, and 
then specify your

widget name space:

  MyApp::Form::User:
  ...
  has '+widget_name_space' = ( default = 'MyApp::Form::Widget' );
  ..
  has 'some_field' = ( widget = 'MyWidget' );

Your rendering widgets will be applied into your field classes.

=head1 Creating Widgets

The new widgets are designed to be used with either the original 
FormHandler
form objects or the new LHTML::FormHandler::Result objects. For that 
reason,
you should use C $field-result  to access the current value, errors 
and

'fif' (fill-in-form) in field widgets, so that they will work
for both form and result rendering.

The basic structure for a field widget:

  package MyApp::Form::Widget::Field::MyWidget;
  use Moose::Role;

  sub render
  {
 my ( $self, $result

[Catalyst] New release of HTML::FormHandler

[Gerda Shank]

The FormHandler DBIC model has been split into a separate package, so 
those using DBIC will need to install HTML::FormHandler::Model::DBIC.


http://search.cpan.org/~gshank/HTML-FormHandler/lib/HTML/FormHandler.pm

http://search.cpan.org/~gshank/HTML-FormHandler-Model-DBIC/lib/HTML/FormHandler/Model/DBIC.pm

Numerous features have been added since the last announcement on this 
list, including Repeatable and Compound fields that represent 
relationships in your DBIC classes. Rendering has been improved 
(although it's still very simple and straightforward). A number of the 
new users seem to like that FormHandler works fine with hand-built 
forms, but allows easy rendering automation where it's appropriate.


And because it's all Moose, all the time, there are lots of nifty things 
you can do, like define your own attributes for the base field class.


There's an irc channel #formhandler on irc.perl.org,  a mailing list at 
http://groups.google.com/group/formhandler, and code repositories at 
http://github.com/gshank/html-formhandler/tree/master and 
http://github.com/gshank/html-formhandler-model-dbic/tree/master


Gerda Shank



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] can't seem to install local::lib in dreamhost

[Gerda Shank]

kakim...@tpg.com.au wrote:

hi guys

 I refered to http://www.catalystframework.org/calendar/2007/8 to
install local::lib into my dreamhost account.

I downloaded the tar file for local-lib and extracted it to a place in
my home dir.
In changed into the directory that local-lib contents lived in.
I ran perl Makefile.PL --bootstrap PREFIX=/home/kakimoto -- went OK
I ran make  test -- went OK
I ran make install and this is the error I got:


[apocalypse]$ make install
mkdir /usr/local/lib/perl: Permission denied at
/usr/share/perl/5.8/ExtUtils/Install.pm line 112
make: *** [pure_site_install] Error 13
[apocalypse]$

  


I recently installed local::lib on Dreamhost and had a lot of problem, 
many - but not all - of which were caused by the fact that they kept 
killing my CPAN install processes. I saved at least a partial log, and 
this is probably what caused his problem:


-
[lakers]$ perl Makefile.PL --bootstrap
Attempting to create directory /home/gshank/perl5
Attempting to create file /home/gshank/perl5/.modulebuildrc
ExtUtils::MakeMaker version 6.31 required--this is only version 6.30_01.
BEGIN failed--compilation aborted.
CPAN version 1.8 required--this is only version 1.7602.
BEGIN failed--compilation aborted.
Prototype mismatch: sub ExtUtils::MakeMaker::prompt ($;$) vs none at -e 
line 9.


/home/gshank/.cpan/CPAN/MyConfig.pm initialized.


After which it  tried to use CPAN to install ExtUtils::MakeMaker. Which 
didn't work, of course.


I downloaded and installed it myself by hand in the perl5/lib/perl5 
directory I think. As I recall, I also had to do that with 
Module::Build. Then eventually it got half installed and I and updated 
my .bashrc myself and then...  evenutally I got it all working. I had 
weird problems with CPAN too. I had to end up installing a lot of the 
modules myself.


Gerda Shank






___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Announce: HTML::FormHandler

[Gerda Shank]

Bill Moseley wrote:


Argh.  My apologies to Gerda.  Gerda wanted to convert Form::Processor
to Moose and had put a lot of work into it.  I couldn't get the
versions Gerda sent to me to pass the tests on the my applications
that user Form::Processor. Unfortunately, work took a higher priority
than changing method makers from Rose::Object to Moose.
  
It's tough to maintain compatibility with major changes in architecture. 
And finding time is always a challenge...

I missed any discussion of a new module, and its name. I purposely
didn't use HTML in the module name because Form::Processor isn't
just about building HTML forms.  The existing form modules at the time
were focused (in part) on HTML generation (which I never need), but
what I needed was a way to move data in and out of the model layer via
forms.  Indeed, my application's API use Form::Processor as well as
command line scripts -- and there's no HTML in those actions.

  
FormHandler works the same in this respect--but I do think that 
processing HTML forms is the central use case, so I don't think an HTML 
in the name will lose many users...


Thanks again for the good work on Form::Processor.

Gerda






___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Announce: HTML::FormHandler

[Gerda Shank]

HTML::FormHandler is an HTML form class written in Moose. It allows you 
to define HTML form fields and validators. It can be used for both 
database and non-database forms, and will automatically update or create 
rows in a database.


One of its goals is to keep the controller interface as simple as 
possible, and to minimize the duplication of code. In most cases, 
interfacing your controller to your form is only a few lines of code.


You can split the pieces of your forms up into logical parts and compose 
complete forms from FormHandler classes, roles, fields, collections of 
validations. You can write custom methods to process forms, add any 
attribute you like, use Moose before/after/around. FormHandler forms are 
Perl classes, so there's a lot of flexibility in what you can do.


http://search.cpan.org/~gshank/HTML-FormHandler-0.19/

gshank


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Hello, Deployment of Catalyst apps in a shared web hosting account without shell

[Gerda Shank]

Ari Constancio wrote:

I'm new to Catalyst, and would like to know if it is possible to
deploy Catalyst apps in a shared web hosting account without shell?
For what I've read, it seems not possible but I need to be sure.
  
I have a Catalyst app deployed on shared hosting (with shell access), 
and if I had to do it without shell access, in theory I suppose that I 
could copy my locally installed Perl and my app directories and get it 
to work. You wouldn't need to use cgi, you could use fastcgi and an 
.htaccess file. The key would be to set it up somewhere where you do 
have access and copy it over.


But I really don't recommend it. You get really poor access to error 
messages and there's just too much you can't do, so quite possibly you 
might not be able to get it to work at all. There are a number of pretty 
cheap shared hosting sites (around $60 per year) that do allow shell 
access. I suggest you choose one of them. There's a list of some of them 
on the Catalyst wiki at:

http://dev.catalystframework.org/wiki/annotated_list_of_catalyst-friendly_web_hosting_providers

Gerda






___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Sending email from a Catalyst app

[Gerda Shank]

ivorw wrote:

The only trouble is I'm struggling to get it working. Using Sendmail as
the mailer sends the mail out - I receive it no problem, but the
application gets an exception error when closing pipe to
/usr/bin/sendmail. No child processes ...

  
I see that you have moved on to other packages, but just thought that 
I'd mention that I got this error executing a Perl system call using the 
development server because Catalyst::Engine::HTTP contains:

local $SIG{CHLD} = 'IGNORE';

Commenting this line out makes the error go away. I have no idea if 
there are other downstream issues. But the non-development servers don't 
do this, so you won't get the error there.


Gerda


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] DBIx::Class model for Form::Processor

[Gerda Shank]

If anybody is interested in trying my DBIx::Class model for 
Form::Processor let me know.


I'm working on tests and packaging it for CPAN now.

Gerda Shank


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Form::Processor and DBIC

[Gerda Shank]

I see that Form::Processor works from CDBI. Is there some way to get it 
to work with DBIC?


G.Shank


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] The Catalyst book?

[Gerda Shank]

When will the Catalyst book be published?

I don't see it on the Packt publishing list

Gerda Shank

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Directory layout

[Gerda Shank]

Thanks for the responses to my question about the View Directory. I'm 
still trying to figure out the reasons for the rest of the directory layout.


The templates are not in the View directory, because the lib hierarchy 
is just for Perl code. Is that right?


Is root kind of the equivalent of htdocs?  What else would go in the 
static subdirectory besides images? Would you put css files in here? 
Does javascript go in static, or does it get a directory underneath root?


Are any parts of the layout created by catalyst.pl changeable, or 
would it break Catalyst to rename them? If, for example, root was 
changed to htdocs, or you didn't use the static directory?


Sorry for all the questions. I've been studying the documentation, but 
haven't had much like finding explanations for these things, and I'm not 
sure where to look in the code.


Thanks,
Gerda Shank






___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/