Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^4: Model-View-Controller: Template Toolkit vs. XSLT

by sri (Vicar)
on Oct 15, 2004 at 20:55 UTC ( #399661=note: print w/ replies, xml ) Need Help??


in reply to Re^3: Model-View-Controller: Template Toolkit vs. XSLT
in thread Model-View-Controller: Template Toolkit vs. XSLT

abysmal error handling and recovery (mostly inherited from UNIVERSAL::require)
I don't get what you mean with "inherited from UNIVERSAL::require", but error and recovery is nice with the new exception handling.
Bad documentation
There are still some small holes but it got a lot better since we are using Test::POD::Coverage. ;)
Bad extensibility as soon as more than one object is involved in one action
TIMTOWTDI, I tend to like Maypole::Component for complex stuff.
Bad logging infrastructure, ranging from nonexisting logging to wildly spewed warnings that can't be disabled
Dunno what you mean with "wildly spewed warnings that can'be disabled", you have to overload debug() to enable debug information.
sub debug { 1 }
What would you expect from a "good" logging infrastructure?


I already invited you to our mailing list, it would be much more productive to post your complaints there. ;)


Comment on Re^4: Model-View-Controller: Template Toolkit vs. XSLT
Download Code
Re^5: Model-View-Controller: Template Toolkit vs. XSLT
by Corion (Pope) on Oct 15, 2004 at 22:09 UTC

    I think I came across a bit harsh - I see these holes, and they need to be fixed, but I currently don't have the time/energy to fix them. Most of the complaints stem from the code as Simon wrote it, and I understand that he wrote most of the code as proof of concept. But this implies to me that more work needs to be done before one can use Maypole in a business setting. Personally, I already use Maypole for my pet project(s), but I'm not really content with the time that I spend hunting down errors.

    UNIVERSAL::require eats/hides compilation errors in the required modules and does not propagate raised errors into $@, but into $UNIVERSAL::require::ERROR, a variable that is not checked and not documented anywhere - this blame goes in equal parts to Schwern who wrote it and Simon Cozens who used it.

    I haven't looked at the development versions of Maypole, but for Maypole 1.7, the current CPAN version, much of the needed documentation needs to be hunted down in the Maypole Wiki and on the Maypole mailing list and can't be divined from the Pod.

    My beef with the Maypole concept of creating a URL stems from an actual example - Maypole URLs look like :

    /$application/$table/$action/$row_id

    but in my application, a photo gallery, I want to display an image in a resolution, and the image filename and the resolution parameters come from the database. Maypole provides no nice way in which the above scheme can be conveniently expanded to take more than one table/row_id, except adding them as CGI query parameters - but then, why have the "fancy" URL in the first place?

    "Wildly spewed warnings that can't be disabled" occur in Maypole::Session::AuthCookie, which has tracing/debugging warnings left enabled and fills up the logs nicely with it. I'd like something along the log levels of LWP or DBI, where you have a good granularity of what you want to see and how much of it.

    I did not post these points as complaints, I see these points more as "things to be fixed" - and while I plan to work on these points, I don't have the time and energy currently. I'll join the mailing list soonish I hope, but there are also talk proposals to be written and real life to be managed ...

      UNIVERSAL::require eats/hides compilation errors in the required modules and does not propagate raised errors into $@, but into $UNIVERSAL::require::ERROR, a variable that is not checked and not documented anywhere - this blame goes in equal parts to Schwern who wrote it and Simon Cozens who used it.
      Wrong, it propagates errors to $@. We already talked about that?
      I haven't looked at the development versions of Maypole, but for Maypole 1.7, the current CPAN version, much of the needed documentation needs to be hunted down in the Maypole Wiki and on the Maypole mailing list and can't be divined from the Pod.
      Well, 1.7 is very very outdated.
      My beef with the Maypole concept of creating a URL stems from an actual example - Maypole URLs look like : /$application/$table/$action/$row_id but in my application, a photo gallery, I want to display an image in a resolution, and the image filename and the resolution parameters come from the database. Maypole provides no nice way in which the above scheme can be conveniently expanded to take more than one table/row_id, except adding them as CGI query parameters - but then, why have the "fancy" URL in the first place?
      You can just overload parse_path() with whatever you want!
      It's very simple.
      sub parse_path { my $self = shift; $self->{path} ||= "frontpage"; my @pi = split /\//, $self->{path}; shift @pi while @pi and !$pi[0]; $self->{table} = shift @pi; $self->{action} = shift @pi; $self->{args} = \@pi; }
      "Wildly spewed warnings that can't be disabled" occur in Maypole::Session::AuthCookie, which has tracing/debugging warnings left enabled and fills up the logs nicely with it. I'd like something along the log levels of LWP or DBI, where you have a good granularity of what you want to see and how much of it.
      Ok, i'm not the maintainer of Maypole::Authentication::UserSessionCookie thats Marcus Ramberg, but i will tell him to fix that.
      You can also use my Maypole::Authentication::Abstract which is a bit cleaner.
      I think we already have a good granularity with debug().
      I did not post these points as complaints, I see these points more as "things to be fixed" - and while I plan to work on these points, I don't have the time and energy currently. I'll join the mailing list soonish I hope, but there are also talk proposals to be written and real life to be managed ...
      Hehe, most of your "things to be fixed" (if not all) are already fixed. ;)
      We have a strong and growing community, so things change very fast.

      The mailing list is not that big, it's easy to follow.
      But you can also visit us in #maypole at irc.perl.org.
        If you consider version 1.7 to be very, very outdated, why is it still current on CPAN?

        Most people will get their versions of your software from CPAN. If that sucks, they will (IMO rightly) conclude that your software sucks. Because the version that they see really does suck. The right solution is to make a non-sucky version of the software available for wider use. The wrong solution is to tell users that they need to learn the secret handshakes and become part of the development community for your software.

        Most potential users think that they have better things to do with their time than become developers. That also applies to most of the people who might eventually become developers on your project.

        I don't care if you don't believe me. But paying attention to how you work with the broader community will result in your group growing even faster and becoming even stronger than it already is.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://399661]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (7)
As of 2014-09-23 05:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (210 votes), past polls