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_______________________________________________ maypole mailing list maypole at lists.netthink.co.uk http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT