David Baird wrote:
> I think we're on a hiding to nothing if we try and predict things such
> as what different types of page/request there might be. We'll miss
> something. And we'll be tempted to handle different types slightly
> differently, and suddenly you have to understand the whole codebase
> and a bunch of special cases before you can predict what happens to
> different page types.
One starting point for this discussion was our general confusion over
why the codebase did something and how to deal with one specific page
type and the lack of a clear description. I do believe it's important to
make some stab at establishing requirements.
> I'm thinking of something more abstracted, possibly modelled on
> Apache's request phases, possibly even more abstracted than that.
<snip description>
> Build your own Maypole.
Sounds like Catalyst to me :)
> At the moment, I'm hoping such a scheme could be fully backwards
> compatible. Maypole works very well as it stands, this is about
> flexibility and maintainability, not about change. But I think
> changing exception handling is more likely to break BC - especially
> since we still haven't found anyone who understands Maypole's current
> strategy.
I've suggested breaking backwards compatibility a couple of times now.
Normally I'm a believer in BC, but it seems to be overly constraining
here. And the only objections I've seen have been on grounds of
principle. Nobody has said that they have a codebase where changes would
be a problem, despite me explicitly asking for feedback. OTOH, nobody
has said they think changes are a great idea either :(
You said yes to my suggestions about send_output() and the template test
in process() and you didn't object to my movement of two lines from
parse_location() to handler(). I don't think those changes are BC - they
change the interfaces between modules.
> I agree with your last point, config is not the place for that stuff.
> But everything is already overridable in the templates, I'm not sure
> what you mean by that.
Sorry, I'm being sloppy. It's been a long time since I used any of that
because IMHO it's so bad. Some things are packaged as objects, which you
can't easily override in TT. They need to be plain hashes. Then there's
just absolutely basic things like dealing with plural table names and
multi-word table and column names and allowing different naming
conventions for FKs and PKs that aren't dealt with properly.
> We've discussed before that it's handy, but feels theoretically wrong,
> to put things like printable labels for columns in the model classes.
> I've stopped thinking about Maypole's model classes as the Model in
> MVC. I think Maypole provides the V and C of an MVC system, and that
> Maypole's models are mostly V.
>
> But yes, it would be nice if such things could be fetched from
> somewhere accessible to designers, rather than embedded in Perl
> modules. I haven't thought much about this though, because I tend to
> work on small projects where roles are shared.
And you use Mason, so you're using Perl in the templates anyway :)
> There's a voice telling me, put all that stuff in a database, wrap a
> Maypole app around it, and give it to the designers...
It's certainly possible to do that - it can be a good solution for
internationalization. Implementations typically force a linear space of
text fragments (like MSG097135), which can be a pain to make comfortable
to live with. And if the backing store is a database, you need cacheing
to avoid lots of DB requests per template. My static hashes are just a
more simple-minded solution.
>> call_exception
>> --------------
>> Does anybody use this mechanism?
>>
>> It doesn't make much sense to me to have a method in the model that
>> handles exceptions elsewhere:
>>
>> - if authenticate dies, something weird is happening (perhaps an
>> attack?) and we don't want to delegate that. You get to write
>> authenticate, so you can put whatever error trapping you want directly
>> in it.
>>
>> - if the view dies, why would the model know anything about what to
>> do? And why is it safe to run the view again OUTSIDE an eval to report
>> the error. Surely the likelihood of that dying is quite high?
>>
>> - come to that, if you're going to write an exception handler in a
>> model class, it means you're already fiddling with the model class. So
>> you might as well just add the error trapping to the process method.
>>
>> So can we deprecate the call_exception mechanism?
>
> I hadn't spotted this, I'll add it to the Great Imponderables!
> But in fact I do use the call_exception mechanism, although not with
> exception methods in the models, maybe that's the part you're talking
> about deprecating? It would be very useful if anyone could come up
> with a use case for this.
Yes I do mean the model part - my Maypole.pm strawman may be clearer :)
Does that fit your needs - if not, what needs to be different?
>> $r->query deleted
>
> If we can keep everything BC, I don't see any advantage to removing
> this. There's a lot of code out there using either name.
There seems to be surprisingly little code in Maypole that uses it and
again I haven't heard screams from people saying such a change would be
too onerous. Besides, query and param used to be different and were made
the same, breaking BC, and that didn't cause gnashing of teeth. And
SimonF was proposing changing them again IIRC.
The advantage is just simplicity and clarity. I don't think the basics
of Maypole are fundamentally difficult. They're just obscured by 1001
details like "what's the difference between params and query?", and
apparently unnecessary circular dependencies between the parse_this and
parse_that methods, is CGI::Maypole a backend or a frontend, and ... on
and on.
Cheers, Dave
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Maypole-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-devel
