At this time bweb design needs *only* 2 things about files location
- static elements are located in /bweb
- all cgi are in the same directory (but where you want)
I'm agree, /bweb path will be better as an option. This makes tpl files
more harder to read but i can also add a script that help user to change this.
For .cgi or .pl extension, if you don't want to modify bweb, you can also
configure apache to do the work.
For example, you can overwrite your fastcgi options in the <directory>
section (or with a htaccess). You can also use rewrite stuff to do what you
want.
If the user have a complexe or strange setup, I think that it's better to
read the apache doc or run a sed command than adding a lot of code/and/or/bug
to the software.
On Friday 12 October 2007 09:47:12 Tuomas Jormola wrote:
> 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
-------------------------------------------------------------------------
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
