Proposed Changes to Knop Form

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposed Changes to Knop Form

stevepiercy
Knop form does a pretty good job of rendering widgets, except
for the few times it does not.  For example, to gain compliance
with Twitter Bootstrap themes, I must iterate through the form
fields and do many replacements on each field's rendering
including errors.

The -template parameter and ->settemplate method add some
flexibility, but not enough for my liking, especially for radios
and checkboxes.

Here's a proposal.  Add a new parameter to the ->addfield
method, -widget='{template}'.  When ->renderform is called, then
the {template} Lasso code will be executed using the other
parameters for ->addfield and defaults for the field type as
currently defined in Knop.

Basically it follows a model I am using in deform, where each
widget uses a template using Chameleon, a template language.

https://github.com/Pylons/deform/tree/master/deform/templates

Thoughts or comments?

--steve

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Steve Piercy               Web Site Builder              
Soquel, CA
<[hidden email]>                  <http://www.StevePiercy.com/>


--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

list
I suggest looking at the enhancements made in Knop for 9.
Specifically the optional param -bootstrap for radio and checkbox fields that makes the output bootstrap friendly.
Another feature to look at would be the changes made to label, introducing support for labelstart and labelend. Or the support for -helpblock.
And of course the support for HTML 5 field types like 'url', 'email', 'number', 'tel' etc.

These enhancements have made Knop for 9 forms play well with bootstrap without the need to do any extra processing field by field.

I can however still see a usefulness of the -widget param. Possibly that the term can be confusing. It would serve the same purpose as the -template does for grids. Too bad the term template is already in use in forms.

Do you have any example of how the -widget would be used?

HDB
Jolle

11 aug 2013 kl. 04:37 skrev Steve Piercy - Web Site Builder <[hidden email]>:

> Knop form does a pretty good job of rendering widgets, except
> for the few times it does not.  For example, to gain compliance
> with Twitter Bootstrap themes, I must iterate through the form
> fields and do many replacements on each field's rendering
> including errors.
>
> The -template parameter and ->settemplate method add some
> flexibility, but not enough for my liking, especially for radios
> and checkboxes.
>
> Here's a proposal.  Add a new parameter to the ->addfield
> method, -widget='{template}'.  When ->renderform is called, then
> the {template} Lasso code will be executed using the other
> parameters for ->addfield and defaults for the field type as
> currently defined in Knop.
>
> Basically it follows a model I am using in deform, where each
> widget uses a template using Chameleon, a template language.
>
> https://github.com/Pylons/deform/tree/master/deform/templates
>
> Thoughts or comments?
>
> --steve

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

list
11 aug 2013 kl. 07:30 skrev <[hidden email]>:

> Do you have any example of how the -widget would be used?

To live up to my own request. Here's a code example using Knop for 9 form and it's enhancements.

<?LassoScript

/* Configuring the form*/
var(fForm = knop_form(
        -formaction = '/path/to_grid/',
        -method = 'post',
// -database = $dBase,
        -id = 'editForm',
        -legend = 'My savvy knop form',
        -actionpath = 'edit',
        -raw = 'novalidate', // not sure if -raw is a 9 addition or not. But it's very useful
        -noscript))

$fForm -> addfield(
        -type = 'number',
        -name = 'mynumber',
        -id = 'mynumber',
        -dbfield = 'my_number',
        -required,
        -class = 'input-small', // A bootstrap type of class helping in rendering it
        -label = 'My number',
        -helpblock = 'Ah, here is the help to get this started',
        -raw = 'min=0 max=100 step=5 data-twin="hernumber"')

$fForm -> addfield(
        -type = 'email',
        -name = 'myemail',
        -id = 'myemail',
        -dbfield = '',
        -required,
        -hint = 'Remember the @',
        -class = 'has_twin',
        -label = 'My email',
        -helpblock = 'This is for your email address',
        -raw = 'maxlength="255"')

$fForm -> addfield(
        -type = 'checkbox',
        -name = 'mycheckbox',
        -id = 'mycheckbox',
        -dbfield = 'my_checkbox',
        -required,
        -value = '1',
        -options = array('1' = 'Yes', '0' = 'No'),
        -label = 'My Checkbox')

/* Rendering the form*/

/* Set the template for the form */
$fForm ->  setformat( -template = '<div id="#id#_cg" class="control-group #errorclass#">
        #labelstart# #required##labelend#
        <div class="controls">
                #field#
                <small class="help-block">#helpblock#</small>
        </div>
</div>')

/* Show beginning of edit form */
$fForm -> renderform(-start)


?>

        <div class="row-fluid">
                <div class="span12">
                        <div class="row-fluid">
                                <div class="span4">
        <?= $fForm -> renderform( -name = 'mynumber') ?>
                                </div>
                                <div class="span4">
        <?= $fForm -> renderform( -name = 'myemail') ?>
                                </div>
                                <div class="span4">
        <?= $fForm -> renderform( -name = 'mycheckbox', -bootstrap) ?>
                                </div>
                        </div>
                </div>
        </div>

<?LassoScript
/* Change the template for the form */
$fForm ->  setformat( '#field# \n')
/* Show the form buttons */
$fForm -> renderform( -type = array( 'submit', 'reset'), -bootstrap)

/* Show the ending form tag */
$fForm -> renderform( -end)

?>


The resulting HTML
<form action="/path/to_grid/" method="post" id="editForm" novalidate>
        <input type="hidden" name="-action" value="edit" />
        <fieldset>
                <legend>
                        My savvy knop form
                </legend>
                <div class="row-fluid">
                        <div class="span12">
                                <div class="row-fluid">
                                        <div class="span4">
                                                <div id="mynumber_cg" class="control-group ">
                                                        <label for="mynumber" id="mynumber_label">
                                                                My number *
                                                        </label>
                                                        <div class="controls">
                                                                <input type="number" name="mynumber" class="input-small" id="mynumber" min=0 max=100 step=5 data-twin="hernumber" value="" />
                                                                <small class="help-block">
                                                                        Ah, here is the help to get this started
                                                                </small>
                                                        </div>
                                                </div>
                                        </div>
                                        <div class="span4">
                                                <div id="myemail_cg" class="control-group ">
                                                        <label for="myemail" id="myemail_label">
                                                                My email *
                                                        </label>
                                                        <div class="controls">
                                                                <input type="email" name="myemail" class="has_twin" id="myemail" maxlength="255" value="" placeholder="Remember the @" />
                                                                <small class="help-block">
                                                                        This is for your email address
                                                                </small>
                                                        </div>
                                                </div>
                                        </div>
                                        <div class="span4">
                                                <div id="mycheckbox_cg" class="control-group ">
                                                        <label for="mycheckbox" id="mycheckbox_label">
                                                                My Checkbox *
                                                        </label>
                                                        <div class="controls">
                                                                <div class="inputgroup" id="mycheckbox">
                                                                        <label class="checkbox ">
                                                                                <input type="checkbox" name="mycheckbox" id="mycheckbox_1" value="1" checked="checked" /> Yes
                                                                        </label>
                                                                        <label class="checkbox ">
                                                                                <input type="checkbox" name="mycheckbox" id="mycheckbox_2" value="0" /> No
                                                                        </label>
                                                                </div>
                                                                <small class="help-block">
                                                                </small>
                                                        </div>
                                                </div>
                                        </div>
                                </div>
                        </div>
                </div>
                <button type="submit" name="button_save" class="btn btn-primary" id="editForm_button_save4">Click me <i class="icon-chevron-right icon-white"></i></button>
        </fieldset>
</form>

HDB
Jolle
--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

stevepiercy
In reply to this post by list
Very roughly.
--------------------------
[
var('required' = {
     return(params->size != '' ? 'error');
});

var('tpl_inputtext') = {
     local('attrs' = params->get(1));
     local('errors' = params->get(2));
     local(
     'output' = string,
     'errmsg' = #errors->size ? #errors->join('<br>'),
     'errorclass' = #errors->size ? #attrs->find('errorclass'),
     'name' = #attrs->find('name') != '' ? ' name="' +
#attrs->find('name') + '"',
     'id' = #attrs->find('id') != '' ? ' id="' +
#attrs->find('id') + '"',
     'value' = #attrs->find('value') != '' ? ' value="' +
#attrs->find('value') + '"',
     'class' = #attrs->find('class') != '' ? ' class="' +
#attrs->find('class') + '"',
     'for' = #attrs->find('id') != '' ? ' for="' +
#attrs->find('id') + '"',
     'title' = #attrs->find('title') != '' ? #attrs->find('title')
     );
     #output = '
<div class="control-group '+#errorclass+'">
     <label class="control-label"' + #for + '>' + #title + '</label>
     <div class="controls">
         <input type="text"' + #name + #value + #id + '>
         <span class="help-inline">'+#errmsg+'</span>
     </div>
</div>
';
     return(#output);
};

// typical type='text' parameters
local('onefield'= map(
         'dbfield'='name',
         'disabled'='false',
         'errorclass'='error',
         'focus'='true',
         'id'='name_id',
         'label'='Your Name',
         'linebreak'='false',
         'multiple'='false',
         'name'='name',
         'nowarning'='false',
         'originaltype'='text',
         'required'='true',
         'size'='40',
         'title'='What is your name?',
         'type'='text',
         'validate' = $required,
         'value'='',
         'widget' = $tpl_inputtext
));

// mocked out from Knop
var('errors' = array('required','numeric'));

#onefield->find('widget')->run(-params=array(#onefield, $errors));
]
--------------------------
=>

<div class="control-group error">
     <label class="control-label" for="name_id">What is your name?</label>
     <div class="controls">
         <input type="text" name="name" id="name_id">
         <span class="help-inline">required<br>numeric</span>
     </div>
</div>

--------------------------

This would avoid much of the existing ->renderform stuff that
concatenates or appends.  -widget is really a template, but with
a lot more control.  Since -template is already taken, I can't
use that name.  meh.

It would be a parameter to ->addfield:

     -widget = $tpl_inputtest

Then invoke the widget with the parameters, if it exists.

     #onefield->find('widget') != '' ?
#onefield->find('widget')->run(-params=array(#onefield, $errors));

This reduces the maintenance burden for the next shiny thing.  
(Oops, I blinked, now there's Bootstrap 3!)

I imagine that using a compound expression may reduce
performance.  I tried many other ways, including custom tags,
file_read, and so on, but that lead me down a rabbit hole where
I never could execute a dynamic template.

--steve


On 8/11/13 at 7:30 AM, [hidden email] pronounced:

>I suggest looking at the enhancements made in Knop for 9.
>Specifically the optional param -bootstrap for radio and
>checkbox fields that makes the output bootstrap friendly.
>Another feature to look at would be the changes made to label,
>introducing support for labelstart and labelend. Or the support
>for -helpblock.
>And of course the support for HTML 5 field types like 'url',
>'email', 'number', 'tel' etc.
>
>These enhancements have made Knop for 9 forms play well with
>bootstrap without the need to do any extra processing field by field.
>
>I can however still see a usefulness of the -widget param.
>Possibly that the term can be confusing. It would serve the
>same purpose as the -template does for grids. Too bad the term
>template is already in use in forms.
>
>Do you have any example of how the -widget would be used?
>
>HDB
>Jolle
>
>11 aug 2013 kl. 04:37 skrev Steve Piercy - Web Site Builder <[hidden email]>:
>
>>Knop form does a pretty good job of rendering widgets, except
>>for the few times it does not.  For example, to gain
>>compliance with Twitter Bootstrap themes, I must iterate
>>through the form fields and do many replacements on each
>>field's rendering including errors.
>>
>>The -template parameter and ->settemplate method add some
>>flexibility, but not enough for my liking, especially for
>>radios and checkboxes.
>>
>>Here's a proposal.  Add a new parameter to the ->addfield
>>method, -widget='{template}'.  When ->renderform is called,
>>then the {template} Lasso code will be executed using the
>>other parameters for ->addfield and defaults for the field
>>type as currently defined in Knop.
>>
>>Basically it follows a model I am using in deform, where each
>>widget uses a template using Chameleon, a template language.
>>
>>https://github.com/Pylons/deform/tree/master/deform/templates
>>
>>Thoughts or comments?
>>
>>--steve
>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Steve Piercy               Web Site Builder              
Soquel, CA
<[hidden email]>                  <http://www.StevePiercy.com/>


--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

list
11 aug 2013 kl. 12:29 skrev Steve Piercy - Web Site Builder <[hidden email]>:

> This would avoid much of the existing ->renderform stuff that
> concatenates or appends.  -widget is really a template, but with
> a lot more control.  Since -template is already taken, I can't
> use that name.  meh.

I'm not fully convinced. From what I can see it's mostly just a lot more complicated markup with an end result that's exactly the same as using the existing -template with the Knop for 9 bootstrap savvy additions.

You're suggesting this in every form config:
var('tpl_inputtext') = {
    local('attrs' = params->get(1));
    local('errors' = params->get(2));
    local(
    'output' = string,
    'errmsg' = #errors->size ? #errors->join('<br>'),
    'errorclass' = #errors->size ? #attrs->find('errorclass'),
    'name' = #attrs->find('name') != '' ? ' name="' +
#attrs->find('name') + '"',
    'id' = #attrs->find('id') != '' ? ' id="' +
#attrs->find('id') + '"',
    'value' = #attrs->find('value') != '' ? ' value="' +
#attrs->find('value') + '"',
    'class' = #attrs->find('class') != '' ? ' class="' +
#attrs->find('class') + '"',
    'for' = #attrs->find('id') != '' ? ' for="' +
#attrs->find('id') + '"',
    'title' = #attrs->find('title') != '' ? #attrs->find('title')
    );
    #output = '
<div class="control-group '+#errorclass+'">
    <label class="control-label"' + #for + '>' + #title + '</label>
    <div class="controls">
        <input type="text"' + #name + #value + #id + '>
        <span class="help-inline">'+#errmsg+'</span>
    </div>
</div>
';
    return(#output);
};

(And as I understand it you would need different widget vars for different kinds of form field types.)

instead of this in the content file:
$fForm ->  setformat( -template = '<div id="#id#_cg" class="control-group #errorclass#">
        #labelstart# #required##labelend#
        <div class="controls">
                #field#
                <small class="help-block">#helpblock#</small>
        </div>
</div>')

I find the latter way more comprehensible. The end results seem exactly the same.

As for reducing the need for renderform. Knop for 8 as well as knop for 9 can render an entire form with one single call for renderform. Or two calls if you want a different template for the buttons.

I usually call renderform for every field since it allows placement of the field with greater accuracy. For example if you want first name and last name to be on the same row but in different spans and title to appear on the next row. Can't see that your usage of -widget reduces that need.

HDB
Jolle
--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

stevepiercy
In reply to this post by stevepiercy
As far as using one custom tag per template, I stumbled around a
bit, and came up with an idea.

     select(#widget);
         case('widget1');
             widget1(#onefield, $errors);
         case('widget2');
             widget2(#onefield, $errors);
     ...
     /select;

There must be some way to invoke a tag without a name with
parameters, but I can't put my finger on it.

I think I would have to create a new type, [template], and load
them into a namespace, like this:

/Applications/Lasso Professional 8/LassoSites/knop-dev-23/LassoLibraries/template/
     inputtext.inc
     radio.inc

That would move almost all the field template code out of Knop,
still make it easier to maintain, and retain performance.  The
only thing that bugs me is that I still need to use the select
above and modify knop_form, instead of something like this:

     #onefield -> find('widget')
     -> convertStringToTagNameAndRunWithParams(-attrs=#onefield, $errors);

Or I'm just having a brain fart over whatever that is.

--steve


On 8/11/13 at 3:29 AM, [hidden email] (Steve Piercy - Web
Site Builder) pronounced:

>Very roughly.
>--------------------------
>[
>var('required' = {
>return(params->size != '' ? 'error');
>});
>
>var('tpl_inputtext') = {
>local('attrs' = params->get(1));
>local('errors' = params->get(2));
>local(
>'output' = string,
>'errmsg' = #errors->size ? #errors->join('<br>'),
>'errorclass' = #errors->size ? #attrs->find('errorclass'),
>'name' = #attrs->find('name') != '' ? ' name="' + #attrs->find('name') + '"',
>'id' = #attrs->find('id') != '' ? ' id="' + #attrs->find('id') + '"',
>'value' = #attrs->find('value') != '' ? ' value="' + #attrs->find('value') + '"',
>'class' = #attrs->find('class') != '' ? ' class="' + #attrs->find('class') + '"',
>'for' = #attrs->find('id') != '' ? ' for="' + #attrs->find('id') + '"',
>'title' = #attrs->find('title') != '' ? #attrs->find('title')
>);
>#output = '
><div class="control-group '+#errorclass+'">
><label class="control-label"' + #for + '>' + #title + '</label>
><div class="controls">
><input type="text"' + #name + #value + #id + '>
><span class="help-inline">'+#errmsg+'</span>
></div>
></div>
>';
>return(#output);
>};
>
>// typical type='text' parameters
>local('onefield'= map(
>'dbfield'='name',
>'disabled'='false',
>'errorclass'='error',
>'focus'='true',
>'id'='name_id',
>'label'='Your Name',
>'linebreak'='false',
>'multiple'='false',
>'name'='name',
>'nowarning'='false',
>'originaltype'='text',
>'required'='true',
>'size'='40',
>'title'='What is your name?',
>'type'='text',
>'validate' = $required,
>'value'='',
>'widget' = $tpl_inputtext
>));
>
>// mocked out from Knop
>var('errors' = array('required','numeric'));
>
>#onefield->find('widget')->run(-params=array(#onefield, $errors));
>]
>--------------------------
>=>
>
><div class="control-group error">
><label class="control-label" for="name_id">What is your name?</label>
><div class="controls">
><input type="text" name="name" id="name_id">
><span class="help-inline">required<br>numeric</span>
></div>
></div>
>
>--------------------------
>
>This would avoid much of the existing ->renderform stuff that
>concatenates or appends.  -widget is really a template, but
>with a lot more control.  Since -template is already taken, I
>can't use that name.  meh.
>
>It would be a parameter to ->addfield:
>
>-widget = $tpl_inputtest
>
>Then invoke the widget with the parameters, if it exists.
>
>#onefield->find('widget') != '' ?
>#onefield->find('widget')->run(-params=array(#onefield, $errors));
>
>This reduces the maintenance burden for the next shiny thing.  
>(Oops, I blinked, now there's Bootstrap 3!)
>
>I imagine that using a compound expression may reduce
>performance.  I tried many other ways, including custom tags,
>file_read, and so on, but that lead me down a rabbit hole where
>I never could execute a dynamic template.
>
>--steve
>
>
>On 8/11/13 at 7:30 AM, [hidden email] pronounced:
>
>>I suggest looking at the enhancements made in Knop for 9.
>>Specifically the optional param -bootstrap for radio and
>>checkbox fields that makes the output bootstrap friendly.
>>Another feature to look at would be the changes made to label,
>>introducing support for labelstart and labelend. Or the
>>support for -helpblock.
>>And of course the support for HTML 5 field types like 'url',
>>'email', 'number', 'tel' etc.
>>
>>These enhancements have made Knop for 9 forms play well with
>>bootstrap without the need to do any extra processing field by field.
>>
>>I can however still see a usefulness of the -widget param.
>>Possibly that the term can be confusing. It would serve the
>>same purpose as the -template does for grids. Too bad the term
>>template is already in use in forms.
>>
>>Do you have any example of how the -widget would be used?
>>
>>HDB
>>Jolle
>>
>>11 aug 2013 kl. 04:37 skrev Steve Piercy - Web Site Builder <[hidden email]>:
>>
>>>Knop form does a pretty good job of rendering widgets, except
>>>for the few times it does not.  For example, to gain
>>>compliance with Twitter Bootstrap themes, I must iterate
>>>through the form fields and do many replacements on each
>>>field's rendering including errors.
>>>
>>>The -template parameter and ->settemplate method add some
>>>flexibility, but not enough for my liking, especially for
>>>radios and checkboxes.
>>>
>>>Here's a proposal.  Add a new parameter to the ->addfield
>>>method, -widget='{template}'.  When ->renderform is called,
>>>then the {template} Lasso code will be executed using the
>>>other parameters for ->addfield and defaults for the field
>>>type as currently defined in Knop.
>>>
>>>Basically it follows a model I am using in deform, where each
>>>widget uses a template using Chameleon, a template language.
>>>
>>>https://github.com/Pylons/deform/tree/master/deform/templates
>>>
>>>Thoughts or comments?
>>>
>>>--steve
>>
>
>-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>Steve Piercy               Web Site Builder               Soquel, CA
><[hidden email]>                  <http://www.StevePiercy.com/>
>
>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Steve Piercy               Web Site Builder              
Soquel, CA
<[hidden email]>                  <http://www.StevePiercy.com/>


--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

stevepiercy
In reply to this post by list
What do you do if TB changes its pattern for displaying a
control, or you want to use another framework?  You would have
to modify the internals of knop_form and repeat yourself a lot.  
Let's take radio for example using my crappy pseudo-code.

                     case('radio')
                         if(#bootstrap) => {
                         ... 40-50 lines of code
                         else(#bootstrap3) => {
                         ... 40-50 lines of code, pretty much
the same as above
                         else(#zurb_foundation) => {
                         ... 40-50 lines of code, pretty much
the same as above
                         else {
                         ... 40-50 lines of code, pretty much
the same as above

-widget would bypass that, following the DRY principle and
keeping the core of Knop lean, while allowing full control over
templates via external modules.

Another advantage is being able to pin your code to a specific
version with far greater ease, although that may be better
handled through a build process and version control.

--steve


On 8/11/13 at 12:49 PM, [hidden email] pronounced:

>11 aug 2013 kl. 12:29 skrev Steve Piercy - Web Site Builder <[hidden email]>:
>
>>This would avoid much of the existing ->renderform stuff that
>>concatenates or appends.  -widget is really a template, but
>>with a lot more control.  Since -template is already taken, I
>>can't use that name.  meh.
>
>I'm not fully convinced. From what I can see it's mostly just a
>lot more complicated markup with an end result that's exactly
>the same as using the existing -template with the Knop for 9
>bootstrap savvy additions.
>
>You're suggesting this in every form config:
>var('tpl_inputtext') = {
>local('attrs' = params->get(1));
>local('errors' = params->get(2));
>local(
>'output' = string,
>'errmsg' = #errors->size ? #errors->join('<br>'),
>'errorclass' = #errors->size ? #attrs->find('errorclass'),
>'name' = #attrs->find('name') != '' ? ' name="' +
>#attrs->find('name') + '"',
>'id' = #attrs->find('id') != '' ? ' id="' + #attrs->find('id')
>+ '"',
>'value' = #attrs->find('value') != '' ? ' value="' +
>#attrs->find('value') + '"',
>'class' = #attrs->find('class') != '' ? ' class="' +
>#attrs->find('class') + '"',
>'for' = #attrs->find('id') != '' ? ' for="' +
>#attrs->find('id') + '"',
>'title' = #attrs->find('title') != '' ? #attrs->find('title')
>);
>#output = '
><div class="control-group '+#errorclass+'">
><label class="control-label"' + #for + '>' + #title + '</label>
><div class="controls">
><input type="text"' + #name + #value + #id + '>
><span class="help-inline">'+#errmsg+'</span>
></div>
></div>
>';
>return(#output);
>};
>
>(And as I understand it you would need different widget vars
>for different kinds of form field types.)
>
>instead of this in the content file:
>$fForm ->  setformat( -template = '<div id="#id#_cg"
>class="control-group #errorclass#">
>#labelstart# #required##labelend#
><div class="controls">
>#field#
><small class="help-block">#helpblock#</small>
></div>
></div>')
>
>I find the latter way more comprehensible. The end results seem exactly the same.
>
>As for reducing the need for renderform. Knop for 8 as well as
>knop for 9 can render an entire form with one single call for
>renderform. Or two calls if you want a different template for
>the buttons.
>
>I usually call renderform for every field since it allows
>placement of the field with greater accuracy. For example if
>you want first name and last name to be on the same row but in
>different spans and title to appear on the next row. Can't see
>that your usage of -widget reduces that need.
>
>HDB
>Jolle

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Steve Piercy               Web Site Builder              
Soquel, CA
<[hidden email]>                  <http://www.StevePiercy.com/>


--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

list
11 aug 2013 kl. 13:26 skrev Steve Piercy - Web Site Builder <[hidden email]>:

> What do you do if TB changes its pattern for displaying a
> control, or you want to use another framework?  You would have
> to modify the internals of knop_form and repeat yourself a lot.

That's a really good point. Maybe we should have the template handling broken out of the knop_form altogether and put it in a separate method. With some technique to call optional modules for different frameworks.

That could save us both the work to define templates for each form and to define your suggested widgets. Instead you have modules to the "template engine" that you call.

At least in Lasso 9 that would be easy to do. I'll take a look and see what I can work out.

HDB
Jolle
--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

stevepiercy
On 8/12/13 at 6:36 AM, [hidden email] pronounced:

>11 aug 2013 kl. 13:26 skrev Steve Piercy - Web Site Builder <[hidden email]>:
>
>>What do you do if TB changes its pattern for displaying a
>>control, or you want to use another framework?  You would have
>>to modify the internals of knop_form and repeat yourself a lot.
>
>That's a really good point. Maybe we should have the template
>handling broken out of the knop_form altogether and put it in a
>separate method. With some technique to call optional modules
>for different frameworks.
>
>That could save us both the work to define templates for each
>form and to define your suggested widgets. Instead you have
>modules to the "template engine" that you call.
>
>At least in Lasso 9 that would be easy to do. I'll take a look
>and see what I can work out.

While riding my bike to the repair shop, and later while digging
up freakishly huge potatoes from my garden, I realized that a
large portion of ->renderform would be bypassed, and I started
contemplating a new method:

     form->widget(-template='template_name')

Some of the code in that method would be duplicated from ->renderform.

The appeal of loading templates outside of Knop also grew on me
while picking green beans and feeding them to Duke.

Most of the ideas originated from deform, a Python library,
which has a schema (reflecting data structure), form rendering,
validation, javascript, internationalization, and templates.  
The templates rely on a templating language that is very deep
and broad and would take months if not years of effort to
replicate in Knop or Lasso.
http://docs.pylonsproject.org/projects/deform/en/latest/
http://deformdemo.repoze.org/

Indeed I think I will create a new branch in git with my
experiment, and push it to GitHub.  We can compare our
implementations.  I should have some time toward the end of the
week to do the work and have a proof of concept together for
text and radio inputs as examples.

--steve

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Steve Piercy               Web Site Builder              
Soquel, CA
<[hidden email]>                  <http://www.StevePiercy.com/>


--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

Johan Solve-2
In reply to this post by list
At 06.36 +0200 2013-08-12, [hidden email] wrote:
>11 aug 2013 kl. 13:26 skrev Steve Piercy - Web Site Builder <[hidden email]>:
>
>> What do you do if TB changes its pattern for displaying a
>> control, or you want to use another framework?  You would have
> > to modify the internals of knop_form and repeat yourself a lot.
>
>That's a really good point. Maybe we should have the template handling broken out of the knop_form altogether and put it in a separate method. With some technique to call optional modules for different frameworks.

A flexible generic templating engine could be useful for all parts of Knop that generates html. Nav, grid and form.

Either add some kind of support for a third party templating engine like Twig, Mustache, Smarty (sounds a bit difficult), or create a knop_template with a typical Knop style lightweight footprint that can take advantage of Lasso's unique features, just borrowing some conceptual ideas from the full scale templating languages.

I didn't really like the idea of supporting just a specific frontend framework by adding a proprietary parameter like -bootstrap. With a template class, the support for a specific framework could be modularized.


--
     Johan Sölve
     Web Developer
     Montania System AB
     http://www.montania.se

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

stevepiercy
On 8/15/13 at 11:57 PM, [hidden email] (Johan Solve) pronounced:

>A flexible generic templating engine could be useful for all parts of Knop
>that generates html. Nav, grid and form.
>
>Either add some kind of support for a third party templating engine like
>Twig, Mustache, Smarty (sounds a bit difficult), or create a knop_template
>with a typical Knop style lightweight footprint that can take advantage of
>Lasso's unique features, just borrowing some conceptual ideas from the full
>scale templating languages.
>
>I didn't really like the idea of supporting just a specific frontend
>framework by adding a proprietary parameter like -bootstrap. With a template
>class, the support for a specific framework could be modularized.

Indeed, while poking around in Pyramid and other Python web
frameworks, I've been exposed to several templating languages,
including Chameleon, Mako, and Jinja2.  There are lots of
sources from which good ideas can be stolen and adapted for Lasso.

http://wiki.python.org/moin/Templating

With Knop, I've just been playing follow the leader, and not
giving it a whole lot of thought.  This is why it is a good
thing to go outside and play with other languages, then bring
home all the dirty words you learned from the other kids.  ;)

--steve

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Steve Piercy               Web Site Builder              
Soquel, CA
<[hidden email]>                  <http://www.StevePiercy.com/>


--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

Johan Solve-2
In reply to this post by Johan Solve-2
At 23.57 +0200 2013-08-15, Johan Solve wrote:
>A flexible generic templating engine could be useful for all parts of Knop that generates html. Nav, grid and form.
>
>Either add some kind of support for a third party templating engine like Twig, Mustache, Smarty (sounds a bit difficult), or create a knop_template with a typical Knop style lightweight footprint that can take advantage of Lasso's unique features, just borrowing some conceptual ideas from the full scale templating languages.
>
>I didn't really like the idea of supporting just a specific frontend framework by adding a proprietary parameter like -bootstrap. With a template class, the support for a specific framework could be modularized.

RIght now I can really see how a flexible templating engine could be useful, as I'm building a mega dropdown out of a knop nav menu. That takes some extra markup intervened with the normal ul/li/a nav output. Just getting a nested array of maps out of nav would help a lot here... And that might just be a first step towards a templating engine.


--
     Johan Sölve
     Web Developer
     Montania System AB
     http://www.montania.se

--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

stevepiercy
In reply to this post by stevepiercy
At long last, this is now ready for developer testing.  It's
only in form.inc, not the built knop.lasso.  There is currently
only one new widget template in the 'tpl' directory, which is an
input of type text and uses Twitter Bootstrap 3.  Lasso 8 only
at this time.

I will be adding new features to the widgets as I go through
each form field type and its  attributes.  But now that the
basic core is there, this should be super easy to modify going forward.

Questions, comments, and especially pull requests welcome.
https://github.com/knop-project/knop

--steve


On 8/10/13 at 7:37 PM, [hidden email] (Steve Piercy - Web
Site Builder) pronounced:

>Knop form does a pretty good job of rendering widgets, except
>for the few times it does not.  For example, to gain compliance
>with Twitter Bootstrap themes, I must iterate through the form
>fields and do many replacements on each field's rendering
>including errors.
>
>The -template parameter and ->settemplate method add some
>flexibility, but not enough for my liking, especially for
>radios and checkboxes.
>
>Here's a proposal.  Add a new parameter to the ->addfield
>method, -widget='{template}'.  When ->renderform is called,
>then the {template} Lasso code will be executed using the other
>parameters for ->addfield and defaults for the field type as
>currently defined in Knop.
>
>Basically it follows a model I am using in deform, where each
>widget uses a template using Chameleon, a template language.
>
>https://github.com/Pylons/deform/tree/master/deform/templates
>
>Thoughts or comments?
>
>--steve
>
>-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>Steve Piercy               Web Site Builder               Soquel, CA
><[hidden email]>                  <http://www.StevePiercy.com/>
>
>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Steve Piercy               Web Site Builder              
Soquel, CA
<[hidden email]>                  <http://www.StevePiercy.com/>


--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Knop Form

stevepiercy
Here are some screen shots of the rendered widget.
http://imgur.com/a/Gn9nm

--steve


On 10/20/13 at 4:21 AM, [hidden email] (Steve Piercy - Web Site Builder) pronounced:

> At long last, this is now ready for developer testing.  It's only in form.inc, not the
> built knop.lasso.  There is currently only one new widget template in the 'tpl'
> directory, which is an input of type text and uses Twitter Bootstrap 3.  Lasso 8 only
> at this time.
>
> I will be adding new features to the widgets as I go through each form field type and
> its  attributes.  But now that the basic core is there, this should be super easy to
> modify going forward.
>
> Questions, comments, and especially pull requests welcome.
> https://github.com/knop-project/knop
>
> --steve
>
>
> On 8/10/13 at 7:37 PM, [hidden email] (Steve Piercy - Web Site Builder)
> pronounced:
>
> >Knop form does a pretty good job of rendering widgets, except
> >for the few times it does not.  For example, to gain compliance
> >with Twitter Bootstrap themes, I must iterate through the form
> >fields and do many replacements on each field's rendering
> >including errors.
> >
> >The -template parameter and ->settemplate method add some
> >flexibility, but not enough for my liking, especially for
> >radios and checkboxes.
> >
> >Here's a proposal.  Add a new parameter to the ->addfield
> >method, -widget='{template}'.  When ->renderform is called,
> >then the {template} Lasso code will be executed using the other
> >parameters for ->addfield and defaults for the field type as
> >currently defined in Knop.
> >
> >Basically it follows a model I am using in deform, where each
> >widget uses a template using Chameleon, a template language.
> >
> >https://github.com/Pylons/deform/tree/master/deform/templates
> >
> >Thoughts or comments?
> >
> >--steve
> >
> >-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> >Steve Piercy               Web Site Builder               Soquel, CA
> ><[hidden email]>                  <http://www.StevePiercy.com/>
> >
> >
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> Steve Piercy               Web Site Builder               Soquel, CA
> <[hidden email]>                  <http://www.StevePiercy.com/>
>
>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy               Web Site Builder               Soquel, CA
<[hidden email]>                  <http://www.StevePiercy.com/>


--
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
List archive http://lasso.2283332.n4.nabble.com/Knop-Framework-Discussion-f3157831.html
The Knop project and code is hosted at GitHub.
https://github.com/knop-project/knop