On Fri, Sep 28, 2007 at 02:10:00PM +0200, BOLLENGIER Eric wrote:
> Hi,
> 
> > I wanted to try out bweb. It turned out to be a bit frustrating at first
> > because of the fixed names for the CGI scripts and fixed path for the
> > static resources. I don't think it's very friendly to force the user to
> > use the same names for stuff (.pl ending for the scripts and hard-coded
> > /bweb path for the resources) as the developer is using. Instead, IMHO,
> > it should be configurable with defaults behaving just like the existing
> > things do. So after a bit of poking around the source, now I've got bweb
> > installation I like. Description of the patches follow. Feel free to use
> > them if you like or ask any questions.
> 
> IMHO, if you want to change all .pl files to .cgi, you can simply do :
> 
> sed -i 's:\.pl:.cgi:g' cgi/* html/* lib/* tpl/*
> 
> And if /bweb or /cgi-bin/bweb isn't good for you
> 
> sed -i "s:'/bweb/:'/newpath/:g" tpl/* lib/* cgi/*
> sed -i "s:/cgi-bin/bweb:/pathtocgi/bweb/foo:g' tpl/* lib/* cgi/*
> 
> It a lot more simple, isn't it ? 
Well I still argue that having this kinds of restrictions due to
hard-coding is just plain stupid design. Not to mention being unfriendly
towards users. Not everyone might be comfortable with editing stuff with
a buch of sed/perl/whatever one-liners. After you have support
configurable paths/extensions in the code base, for user it's then just
a matter of changing one line in a configuration file (and in case of
the extension support, you don't actually have to do anything since it's
done automatically for you). How simple is that then?

I guess the question is about whether it's simple for the developer or
the user. Even when designing software myself, I tend to side with the
user (i.e. as a user I want to be able to configure my stuff like I want
without touching the code and thusly I should not encounter stupid
restrictions caused by sloppy design). In order to implement this, the
designer should see some extra effort and it requires a bit of
discipline in the future (in this case the way links are created in
templates is mandated to include the URL base variable for instance). So
it's a trade-off (just like so many other things in this world)... But
since this is a public free software project, you're not doing it just
for yourself, I think you should take into account also the users when
making design decisions... YMMV of course.

> 
> > By the way, I think current localization scheme doesn't scale at all
> > (having copies of all the templates for all the supported languages).
> > One might try to improve the situation by externalizing all the strings
> > to HTML::Template variables and then translate them using Locale::PO or
> > something similar so you wouldn't have to update N templates when you
> > have to change the layout...
> 
> Yes, i have ideas to fix that, i think that i will use something like
> _("string to adapt") in the main tpl file, then i will use a script to
> generate all tpl versions.
> 
> Thanks for your feedback.
> 
> Bye

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to