Hello Joshua!
Thank you for fast and detailed answers and support!
You are cool as always.
> > We have a 4 year experience in developing web sites
> > for our customers. Most of these web sites must present
> > information stored in some relational database
> > (MySQL or Oracle), and we create a special web interface
> > for managing the data stored in the database.
> > We cannot use standard modules like DB::Editor,
> > because we need to provide a simple and easy-to-use
> > interface for end user.
> >
> > We used to create such interface using Apache::ASP,
> > but that was incovenient because we could not
> > reuse code for different projects, and it required a programmer
> > and a usability specialist to work togather on such interface
>
> You ever look at XMLSubs in Apache::ASP? It should
> promote code reuse like you are going for. You just
> need to install your XMLSubs module in each of your
> projects.
>
> Also, if you decomp much of your generic application
> logic into some real object, you can init this object,
> say $App, in Script_OnStart, and have it available in
> all scripts just like $Server, $Session, etc.
>
> use vars qw($App $Form);
> sub Script_OnStart {
> my $dbh = DBI->connect(...);
> $App = My::App->new(dbh => $dbh, ...);
> $Form = $Request->Form;
> }
Of course, we know this and used this feature.
>
> The you can reference $App in all scripts & includes,
> just like
>
> <%= $App->print_something %>
But our crew are 3 designers and 4 programmers.
Designers know nothing about $App and other things, programmers don't know
about CSS and other HTML stuff.
As our crew grows we need to separate our jobs.
Our programmers wants more freedom and know about Apache Perl Modules enough
to use clear Apache Perl API.
IMHO Apache::ASP is ideal for webmasters, who write code and HTML. It is
very simple edit all things in one file. Apache::ASP is ideal as starting
point of Web programming. Reach ASP object functionality allows to create
WEB sites fast. But it is not our main goal.
Now, while programmers code clear Perl Module, designers create templates at
the same time. We dont disturb each other (Thanks god, they know about IF
and WHILE :) but it is a limit for them - They are artists, creators, not a
narrowminded programmers - Sorry :) )
We like it.
>
> since all scripts & includes are compiled into the same
> package as global.asa.
>
> For support of the code you mentioned like:
>
> <edit sql="update banned_ip set ip=? where ip=?" params="ip old_ip">
> <delete sql="delete from musica.banned where banned_ip = ?"
params="old_ip">
> <add sql="insert into musica.banned (banned_ip) values (?)" params="ip">
>
> You can define
>
> PerlSetVar XMLSubsMatch edit|delete|add
>
> Then in global.asa, you can define you subs like so:
>
> # assuming edit() represents a widget & db function
> sub edit {
> my($args, $html) = @_;
> my @params = split(/\s+/, $args->{params});
> if($Form->{'edit'}) {
> $App->{dbh}->do("$args->{sql"}, undef, map { $Form->{$_} } @params);
> }
> print "<input type=submit name=edit value=Edit>";
> }
>
> Because these XMLSubs don't have their own namespace you
> would not be able to decomp them into their own perl package,
> but you could put them in a perl module without a package,
> and then use/require/do them from global.asa to import.
> I only suggest this for code reuse between projects.
> You could also have them in a package, and them import
> the functions, but you might have to reference vars like
> $main::App, which you would have to init in global.asa.
>
> Its very easy to not use good coding practice with
> Apache::ASP, but you can use like any other full embedded perl
> environment for good code reuse.
>
> One more thing ... XMLSubs are limited to parsing out only
> the XML attributes & body, so things like FOREACH are harder
> to implement, however a recent feature makes it possible,
> as you can now $Response->Include() scripts data on the fly,
> not just file names, so:
>
> XMLSubs FOREACH|rows|row|inp
>
> <rows name=myrows action=fetch sql="select banned_ip from banned order
by banned_ip">
> ...
> <FOREACH c=myrows>
> <row>
> <inp name="ip" type="text" value=c.banned_ip size="15">
> <inp name="old_ip" type="hidden" value=c.banned_ip>
> </row>
> </FOREACH>
>
> sub rows {
> my $args = shift;
> my @rows;
> my $sth = $App->{dbh}->prepare($args->{sql});
> while(my $row = $sth->fetchrow_hashref) { push(@rows, $row); }
> $App->{rows}{$args->{name}} = $rows;
> }
>
> sub FOREACH {
> my($args, $script) = @_;
> my $rows = $App->{rows}{$args->{c}};
> for my $row (@$rows) {
> $App->{currrow} = $row;
> $Response->Include(\$script);
> }
> }
>
> sub inp {
> my $args = shift;
> my $row = $App->{currrow};
> print "<input name=$args->{name} value=$row->{$args->{name}} ...";
> }
>
> Just as example of how you might achieve what you are going
> for with Apache::ASP. I know you used it before, but the
> application environment has grown considerably over time,
> now in its 4th year of development.
Huh!
Great improvments, as I understand ASP scripts can contains XML tags only
now.
It is what we need, but correct me if I wrong, there are many other
solutions, which do the same more efficient and simpler. This idealogy
(separate code and html) is far away from original ASP idea _embed_ code
into HTML.
Of course, there are ASP OO model, it is cool, but mod_perl API not so
difficult to learn. In most cases, use of pure Apache Perl API is more
simpler and efficient than Apache::ASP for us.
-------------------------------
Sergey "BeerBong" Polyakov
Chief of WebZavod
http://www.webzavod.ru
