[Maypole] 2.07 PR

[Dave Howorth]

Simon Flack wrote:
>> M::V::TT still doesn't allow .tt extensions :(
> I keep changing my mind about this. I think it'd be useful to be able
> to define a template file extension, and it's a relatively trivial
> patch, but I'm not sure it belongs in Maypole. I half expected there
> to be a TEMPLATE_EXT option in TT, but I couldn't find one. I'm not
> ruling out adding $r->config->template_ext, I just need a bit of
> convincing :)

I don't think TT has one, but I'm not sure why it would. TT is agnostic 
about its input filenames; it can process anything. It's Maypole, not 
TT, that cares about having URL components like view that are both valid 
Perl identifiers and template filenames. In general it's the web 
framework that knows about URL mangling, TT doesn't know or care that 
it's being used in a web application. So I think it does belong in 
Maypole philosophically. Pragmatically as well!

> Out of interest, would you expect/desire nested templates to have a .tt 
> extension added? E.g.:
> 
>     [% IF foo;
>         PROCESS another_template; # load "another_template.tt"
>     END; %]

All my templates have a .tt extension because that's what makes it easy 
for vi or emacs or whatever to turn on the appropriate syntax colouring. 
It also makes it easier to find template files in the filesystem for any 
reason. I posted a script that automatically changed all the PROCESS etc 
statements in the [then] factory templates. It was very simple.

>> It's difficult for me to test the templates because mine look 
>> considerably different now. (I've done away with classmetadata.cgi 
>> altogether since it just duplicates to_field; I use my loader to 
>> generate text strings; I use some modified accessor_names (these break 
>> the view_item macro BTW); I check explicitly for primary keys not just 
>> 'id' cols; ...)
> 
> I'd like to see that in the factory templates and in 
> Maypole::Manual::(Request|StandardTemplates) too.

I guess you mean the primary key checks? I check using information that 
my loader extracts from the schema and loads into new template 
variables, so you have to buy into that (or provide an alternative 
mechanism) before the template changes would work for you. Sorry :)

>>> - The addnew template will attempt to prefill form fields with
>>> request parameters
> I should probably qualify "attempt". It should work for <textarea> and 
> <input> fields (and other form fields that use the "value" attribute to 
> set the default value). But it doesn't yet prefill radio buttons. That 
> might not be a problem since CDBI::AsForm doesn't generate radio buttons.

It seems to be OK for me at the moment. I'm working with a heavily 
modified CDBI::AsForm that fixes various problems that have bitten me, 
as per various conversations on the CDBI list, but it doesn't generate 
radio buttons (yet :) I suspect that it's in for some more heavy rework 
after I've got some more serious application issues sorted out. I think 
Peter Speltz also uses a custom AsForm and may need/suggest something.

>> BUT on the list page it also appears to cause search parameters to be 
>> transferred to the addnew box after pressing 'search'. This seems wrong.
> I noticed that, and I thought I'd fixed it by cloning the HTML::Element 
> returned by classmetadata.cgi.$col:
>     SET elem = classmetadata.cgi.$col.clone;
> Do you have that line in your 'addnew' template?

That'll be what that line was for, then :) Sorry. I'll try it tomorrow.

>> M::MM::CDBI::do_edit() still runs create/update_from_cgi in an eval 
>> and puts fatal errors in errors.FATAL. I still think that is wrong; I 
>> think there should at a minimum be an Apache error log entry for a 
>> fatal error.
> I'll add a warn() for that and we can revisit it later.

Thanks, that's a good start.

I actually found some issues with CGI::Untaint today because it doesn't 
seem to provide any way for an untaint handler to pass specific 
validation failure information back to the application. It swallows it 
and passes back its own one-size-fits-all message. My gut feel is that 
I'd like to replace the whole FromCGI and AsForm thing with something 
based on Data::FormValidator (a la FormBuilder). But I have more 
important things to do first.

>> There's a beer/addnew as well as a factory/addnew. beer/addnew looks 
>> out of date, and I don't remember if there's a reason it should exist 
>> at all?
> I can't see why there is one either. Perhaps it is a useful test/demo 
> that you can override a factory template with a model template.

Could be. If so, it ought to be based on the latest factory one.

Cheers, Dave


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/01/05