Re: [Webmacro-devel] What my webapp will offer web designers

[Marc P. <ma...@an...>]

On Tue, 1 Apr 2003 10:29:04 +0200 (CEST), Endre Stølsvik 
<web...@st...> wrote:

> | This sounds good..
>
> I second that..!

Great :-)

> | What I am trying to help you do is to develop a framework which will
> | allow and not preclude an ACID transaction.
>
> However, there are tons of websites that only show .. you know .. text 
> and
> pictures. Companies that only "wants a precense on the Internet".

As far as transaction stuff goes... this webapp does not -force-you to do 
anything specific. It has a framework to make a lot of hassle things easier 
and safer (like auto-scoping of template variables) but it is always 
possible to access the raw WebContext, request and session. So I fail to 
see how it can possibly prevent anything like ACID Transaction handling.

However add-on plugins should make cross-page transaction management very 
convenient. I have an action and helper combination in mind for collating 
fields from multiple pages into author-defined groups. Couple this with a 
generic load/save mechanism for these groups of data and I think you pretty 
much have what Lane is after.

I've also got in mind a JDBC action that will allow SQL transactions across 
a list of actions performed in sequence as the result of a single link. 
i.e. you could do this in the template:

#set $startTxn = $Ignition.newAction( "startSQLTransaction")
#set $saveData1 = $Ignition.newAction( "saveData")
#set $saveData1.DataGroupName = "part1"
#set $saveData1.OnErrorURL = $Ignition.execute( [ $Ignition.newAction( 
"rollbackSQLTransaction") ] )
#set $saveData2 = $Ignition.newAction( "saveData")
#set $saveData2.DataGroupName = "part2"
#set $saveData2.OnErrorURL = $Ignition.execute( [ $Ignition.newAction( 
"rollbackSQLTransaction") ] )
#set $commitTxn = $Ignition.newAction( "commitSQLTransaction")

...OK this isn't beautiful syntax... but it could possibly be cleaned up 
using a #macro

One key thing I am focusing on is deferring serious functionality to 
actions executed on the server as the result of a request, rather than 
executing code "in line" as a template is executed. I personally think the 
latter is a convenience AKA a drity hack, because your error handling in WM 
templates is almost non-existent and you do not have control over the 
response when something goes wrong.

> If this thing was mixed with a content management system (which enforced
> some kind of transaction acidity on the content/articles it creates and
> manages), then you'd have something that would allow most "websites" to 
> be developed fast and good.

Yes - this is precisely the kind of thing I have in mind.

I forgot to include on the list of shipped "plugins":

* SQL database access (SELECTs and INSERTs, maybe UPDATEs)
* Content management of some kind - with abstracted data storage.

> What I'm suggesting, is that ideally this thing should have some DB-based
> CMS "on the side", that allows web-page developers to "fetch" articles,
> with maybe some "#fetcharticle secure $params.CurrentArticle as 
> $article",
> and this would get article as specified by the URL ($params) from the
> database, and put in $article. $article is of Article class, having
> methods like "getElements()" to get all elements, "getElement(int
> which/String namedElement)", "toHTML()" for dumb rendering etc.
>
> Just an idea..

You're bang on track :-)

> And here's another, while I'm at it:
>
> Make the URL parsed something like this:
> http://dontcare/webapp/template/extra/path/info?param1=2&param2=3
>
> Webapp is natural, since that's how Servlets are specified. "template"
> defines which template to use as renderer/'category template', maybe
> simply "name-mapped"  (e.g. directly specifying a template located in 
> e.g.
> WEB-INF/categories/, with ".wm" appended), and "/extra/path/info" is 
> given
> as $pathinfo to this template, as well as all the params in $params.

Well I already have something a little like this - extra path info is 
currently used to locate the "module" to use. You can host many 
"applications" all with their own set of helpers, plugins and actions (as 
well as inheriting the default ones), and you do this using modules. The 
module name is just the part of the URI after the servlet name.

> If extra-path-info was "secured" (e.g. doesn't contain any ".."s), it
> could be used both directly as a template-filename (with path), starting
> form WEB-INF/templates/, being included from the "render-template", or it
> could be used as a cool mapping into some CMS structure in a zillion 
> ways.

I don't think ".." is a problem with WM is it, unless you are using the 
file template provider?

> Or, if the site was small enough, forget about all that, and just use the
> first element, "template" to fetch template directly..

It already supports template names. i.e.:

http://myserver/ignition/ignitionServlet/myModule/index.wmt

This is working.

> The idea is to make a whole set of possibilities open from the start, w/o
> constraining the system too much.

Yep!

> | >
> | > So, as far as web developers are concerned that's it pretty much. It
> | > seems simple, and it is really. That's the beauty of it, I think.
>
> It sounds cool, but.. What about PHP? I mean, there's probably some 
> reason
> why it started out as a simple "Professional Home Page" language, and've
> ended up as "PHP Hypertext Preprocessor" with _tons_ of stash.
>
> But it's not quite what you're making either, maybe? It's not primarily a
> PHP-killer, but more of a Q'n'D website-maker..?

Well yes and no. I think of it as a potential PHP killer because we can get 
a huge bundle of plugins going for free, and people could make their own 
distros if they like (potentially including Tomcat)...

What can you do with PHP that you couldn't do with a "run and go" WM 
application? Sure, you need servlet hosting....

The performance of the WM app should be much better too. I know people who 
have done some benchmarks on PHP vs. Java and found huge increases using 
Java.

-- 
Marc Palmer