WebGUI

I've considered this long and hard (again). And I've made my final decision.

WebGUI will remain database agnostic. At specific points where performance is poor we 
will introduce MySQL specific code through a simple if construct, and if the database is 
not MySQL it will use the ANSI SQL code instead. Because the performance enhancing code 
will be kept in very limited areas of the system, I see no need to create a full 
abstraction layer. Postgres developers (and other db developers) may contribute patches 
to allow for performance enhancers where they see fit as well.

PB will be introducing a new upgrade system during the 6.x cycle. During that time we'll 
work to make the upgrade process more modular, which should help the Postgres community 
plug in code to support upgrades for thier preferred database.

Postgres will remain community supported, therefore PB will not provide any custom 
support for Pg. However, PB will do everything possible to maintain the ANSI SQL 
compliance so that Pg will work reasonbly well. How well wG and Pg work together will 
largely depend upon the efforts of the Pg community at large.

And, on one final more personal note to potential developers... Instead of scathing 
remarks, fork threats, and other public screaming, if you are interested in the future 
direction of WebGUI, stay on the developers mailing list and bring up your points as 
rational, logical, and evidence-backed discussion.

JT ~ Plain Black

Create like a god, command like a king, work like a slave.

When you have stuff like this please mail it to the list and not me directly. 

/* begin sarcasm 

I have also given thought to Expr (H:T:E), but my fear is that people will do exactly 
what you're trying to do and add get and set variables. What's next? Oh, how about we 
add database access? Then what? I think we need web services support! Please don't say 
that it won't happen. Pretty soon it turns into a programming language. 

end sarcasm */

Incidentally, the author of H:T:E is not a fan of it. He say's himself that it is very 
slow and clumbsy compared with H:T.

I may eventually be willing to go down the road of H:T:E. My fear is that the road is 
slippery. So before I say yes, I need to get some better shoes.



On Wed, 20 Aug 2003 13:06:57 +0200
  "Dirk van der Zee" <dirk.van.der.zee@...> wrote:
>Hi JT,
>
>Following the discussion with Leendert about replacing the
>macro/template combo I want to ask your opinion about a change that
>enhances the possibilities of the template module with very little
>effort. I have setup the rationale in a so called "Situation - Target -
>Proposal" (STP) format.
>
>Situation
>Currently WebGUI is using HTML::Template for the UI stuff and there are
>good reasons for that:
>* It is easy to learn for webmasters 
>* It is not "powerful" enough to compromise the security (like Mason)
>* It is fast
>Perhaps there are other benefits but I think these are VERY important.
>
>The problem is that HTML::Template is lacking some important functions.
>There are two I want to mention (but there are more):
>1. Variables cannot be compared (only true / false)
>2. Variables cannot be temporarily set in the template
>One example why this is handy for example is when you want to display
>the list of the USS or Messageboard on category year / month 
>e.g.
>2002
>    Januari
>          Msg1
>          Msg2
>          Msg3
>    Februari
>          Msg4
>          ....
>To do this you need to be able to check if the month or year has changed
>since the previous record.
>For this you need the two capabilities above. Again this is only one
>example.
>
>
>
>Target
>Improve the capabilities of HTML::Template but keep the three benefits
>mentioned above.
>For these reasons and because it is not backwards compatible we can't
>use solutions like EmbPerl and Mason.
>
>
>Proposal
>Include HTML::Template::Expr as additional module and start using this.
>It is written by the same author and it builds on the capabilities of
>HTML::Template.
>So it is 100% compatible, in fact it uses HTML::Template and adds some
>features such as comparing variables, arithmetic, etc.
>Another benefit is that you can register your own functions. For example
>there are no functions for GET and SET of variables yet but such
>function is created in just a few lines of code. 
>I have attached a slightly changed version of Expr.pm. The changes are
>1. Removed a bug (omission) in parsing variables to allow dots (.) in a
>variable name (this is done via a regular expression)
>2. Include the two functions: "setvar($name,$value)" and
>"getvar($name)".
>
>Implementation
>* The included file needs to be copied to ../lib/HTML/Template/
>* The change in the default WebGUI code is minimal: 
>   In template.pm there are two lines HTML::Template which need to be
>replaced with HTML::Template::Expr.
>* You need to include Parse::Descent.pm in the package because that's
>what Expr.pm uses for parsing
>
>
>What do you think?
>
>
>Best regards,
>Dirk van der Zee
>p.s. I have sent this directly to you but let me know if you prefer
>otherwise.

JT ~ Plain Black

Create like a god, command like a king, work like a slave.

>You are obviously far from convinced that template plugins could offer
>advantages, or you are very reluctant to change one of the core features
>of WebGUI. And you will probably have good reasons for that.

I am reluctant, but not because I don't like change. Instead, because I like to weigh 
the advantage gained versus the work involved, the ease of use achieved, and the speed 
impacts.

>I find Macros perfect when performing small, straightforward tasks, that
>doesn't need you to provide it with a bunch of (opaque) parameters. But
>in some cases, you need to pass a bunch to get the job done. I thought
>that template plugins could enhance template writing and reading and
>prevent obfuscated code. But you are right, it also has its
>disadvantages (we didnt even speak about development of these plugins,
>which will probably be a lot harder than programming Macros), and is
>somewhat redundant when macros are available.

I will admit that the Macro/Template combo is not perfect, but it is the best thing I've 
seen to date to keep the content seperated from the logic. If these plug-ins that you're 
talking about would make the world better, then I want to explore them. I require hard 
evidence, and that is what I'm pushing you for.

>I'll drop the discussion.

I don't want you to drop the discussion unless you want to. Don't drop it just because 
I'm pushing back on you. When I don't understand something (or don't believe it) I 
always push back because I don't believe in jumping on every idea just because someone 
conceived it. I need to know that we're going down a path of massive benefit. There is 
so much that can be done with WebGUI, but there is very little time (even with the 
support of the open source community) so I've got to pick the battles that get the big 
wins.

JT ~ Plain Black

Create like a god, command like a king, work like a slave.