Hi,
Now when I think about this I think that you are probably right that
the designer does not normally need to change the type of the field.
The attributes, possibility to intersperse the inputs with additional
tags and to change the order of fields should be quite reasonable
range of customisation. I would not care too much about fieldsets and
ul/ols in HTML::Widget - I would just left that for the templating,
but I would generate the hidden fields by the start_form helper.
Unfortuntely I don't have any experience with designers in a Catalyst
project. The interface_config.dat should not be too complicated - and
it can be made a bit simpler by choosing a separate directory for it
and having separate files for each Controller, and also by using some
config language instead of Perl datastructures. But if it is only
used by InstantCRUD than I am afraid people would not accept it.
And where is that guy that started me thinking about this with his Rails email?
--
Zbyszek
On 11/6/06, Carl Franks <fireartist@xxxxxxxxx> wrote:
On 03/11/06, Zbigniew Lukasiak <zzbbyy@xxxxxxxxx> wrote:
> First of all my goal was to make Catalyst::Example::InstantCRUD an
> easy starting point for learning programming in Catalyst. This means
> that the user should be able to start playing with the presentation
> layer without the fear to break something in the more invisible
> business logic parts.
> Accidentaly (or perhaps not) this kind of separation would also be
> good for bigger teams - where you could let the designer work with the
> templates - and the programmers with other parts of the project. Of
> course we could get rid of generating the form entirely and have
> everything in the templates - but then we would have to code the logic
> for errors and stickiness etc in the templating language which is too
> simple for tasks like that. So what is left is some smart HTML tags -
> and the example of Rails shows that this can work.
>
> I have also the idea of scaffolding - so that the programmer could
> build a form reasonably good looking without the help of the designer
> and have just: [% result %] in the template. But then the designer
> would come to the project and he could override the defaults provided
> by the programmer with:
>
> [% result.form_start %]
> [% result.textfield( foo ) %] <br>
> [% result.textarea( bar ) %] <br>
> [% result.checkbox( baz ) %] <br>
> <input class="submit" id="widget_ok" name="ok" type="submit" value="Create" />
> </form>
Being able to start with just [% result %] in the template, and then
have a route to customization is a good goal.
What's your experience been like with pointing designers at the
interface_config.dat file to make those kind of changes?
It looks like a simple enough syntax, that anyone should be able to
make changes without too much difficulty. ( Is that wishful thinking?
:)
A complication with the proposed method above, is that a widget will
have at least 1 fieldset element, but may have any number of hidden
fields, nested fieldsets, divs, spans, ul/ol's.
Would we want the methods in your example above to be smart enough to
print elements earlier in the form, and any opening tags?
Likewise, we'd need a form_end() method which closes all the tags.
This would mean you couldn't rearrange the order of elements, using
these methods.
It would also mean having to ditch HTML::Element and write our own xml
generator.
Or if you were using these methods, would it suffice that you can only
use form-related elements (no fieldset, div, etc) and that the
designer has to explicitly list all elements?
We could, of course, provide helpers such as
[% result.hidden_fields %] and
[% result.buttons %]
A much easier method to implement would be something like...
[% result.type( 'Textfield', 'foo' ) %]
[% result.type( 'Textarea', 'bar', 'rows', '5' ) %]
[% result %]
But, then, you're kinda making the designer think like a programmer.
I'm working on changing the internals, so you can choose a different
renderer, using TT rather than HTML::Element, for example.
If I get this working, that may help, but you'd still need to make
that decision, as to which renderer to load.
> The problem here would be that there would be some leftovers - in the
> code the programmer would leave
> $w.element('Textfield', baz)
> but in the output this foo would be overriden to be a checkbox. This
> looks a bit unclean - but actually I don't know if this is something
> important here.
If the intension is to let the designer /override/ the programmer's
choices, then it's not really avoidable.
Of course, only allowing changes in "interface_config.dat" would solve that.
> The scaffolding idea is quite powerfull in my opinion. It is about
> designing the library not for a static usage - but rather taking into
> account that the needs of a project change over time.
Being able to set tag attributes from the templates sounds good, but I
question the value of being able to change the element type from the
templates.
Other than changing between textfield / textarea, there can't be many
situations in which it's okay for the designer to change the type,
without the database or validation(controller) layer knowing about it.
Select and RadioGroup elements require a list of labels / values,
which would be unwieldy to pass from the template. (I don't like how
Rails handles Selects).
Checkboxes usually represent a boolean datatype, which ideally would
have a 'Bool' or other appropriate constraint added in the controller,
and use a relevant database column.
I like how Reaction uses TT templates, but they're specific to each
field type, and I don't see how we could use that approach to allow
customization by element name, rather than type.
Hmm, what about creating a $widget by parsing a html file containing
only a FORM tag and the form contents?
The controller code would only need to add constraints / filters.
The designer can change the form html as they wish.
I obviously haven't given this much thought, though...
Well, what can I say? Give me a crude core dump, and you'll get one
back in return!
Carl
_______________________________________________
Html-widget mailing list
Html-widget@xxxxxxxxxxxxxxxxx
http://lists.rawmode.org/cgi-bin/mailman/listinfo/html-widget
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
|
