webmacro-devel

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

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

Hi,

As per Lane's recommendation a few days ago, I'm going to start a couple of 
threads detailing what my forthcoming webapp offes designers and java 
devlopers - treating each separately. Sorry for the delay in all this but 
we had a baby 3 weeks ago and I'm "off work" and doing as much as I can to 
help with caring for our new daughter! OK, on to my other baby...

First let's define what I mean by web designer. I mean anybody who hacks 
together websites, whether professional or amateur, but typically not a 
Java programmer.There are literally tens of millions of would-be web 
designers out there - an order of magnitude more than there are "serious" 
java programmers (i.e. people who can write more than a main() method with 
a for loop in it).

For these "web designers" the webapp will offer a single binary download 
that can be installed immediately in any servlet container and template- 
driven pages can be viewed immediately.

After doing this, they can view the webapp's docs which are served via the 
webapp itself using WM, and "context sensitive" help that tells them 
exactly what request parameters and template variables are provided by the 
actions, helpers and plugins.

They can immediately edit the demo templates and instantly see the changes 
in their browser by hitting Refresh. At this point they already have a 
powerful content system - server side includes, loops, variable passing, 
macros, session vars and so on.

Then they can learn about the more advanced features - helpers, plugins and 
actions - after which they can download these classes from websites, most 
likely webmacro.org, that add more advanced functionality.

Built in to the binary deployment should be some of the most common 
advanced facilities:

* Sending e-mail
* Logging clicks to links
* User login/authentication
* Storage/retrieval of field data by "view id", an arbitrary grouping 
mechanism that spans actions and pages.
* Useful helpers - file system access, date manipulation, simple XML DOM 
access (for RSS display for example)

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.

I'll try to post about the developer side of it tomorrow.

Marc
-- 
Marc Palmer
http://www.wangjammers.org

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

[Lane S. <la...@op...>]

Hi Marc,

This sounds good..

I think my point that I have been trying to raise stems from the issue 
of the lure of having a really easy web app kit and then thinking you 
can do some things like consistent transactions with it out of the box. 
See google "Transaction ACID" for a general discussion on transaction 
consistency and how easy is to get it wrong in a multi-threaded env like 
a single servlet.

What I am trying to help you do is to develop a framework which will 
allow and not preclude an ACID transaction.

-Lane

Marc Palmer wrote:

>
> Hi,
>
> As per Lane's recommendation a few days ago, I'm going to start a 
> couple of threads detailing what my forthcoming webapp offes designers 
> and java devlopers - treating each separately. Sorry for the delay in 
> all this but we had a baby 3 weeks ago and I'm "off work" and doing as 
> much as I can to help with caring for our new daughter! OK, on to my 
> other baby...
>
> First let's define what I mean by web designer. I mean anybody who 
> hacks together websites, whether professional or amateur, but 
> typically not a Java programmer.There are literally tens of millions 
> of would-be web designers out there - an order of magnitude more than 
> there are "serious" java programmers (i.e. people who can write more 
> than a main() method with a for loop in it).
>
> For these "web designers" the webapp will offer a single binary 
> download that can be installed immediately in any servlet container 
> and template- driven pages can be viewed immediately.
>
> After doing this, they can view the webapp's docs which are served via 
> the webapp itself using WM, and "context sensitive" help that tells 
> them exactly what request parameters and template variables are 
> provided by the actions, helpers and plugins.
>
> They can immediately edit the demo templates and instantly see the 
> changes in their browser by hitting Refresh. At this point they 
> already have a powerful content system - server side includes, loops, 
> variable passing, macros, session vars and so on.
>
> Then they can learn about the more advanced features - helpers, 
> plugins and actions - after which they can download these classes from 
> websites, most likely webmacro.org, that add more advanced functionality.
>
> Built in to the binary deployment should be some of the most common 
> advanced facilities:
>
> * Sending e-mail
> * Logging clicks to links
> * User login/authentication
> * Storage/retrieval of field data by "view id", an arbitrary grouping 
> mechanism that spans actions and pages.
> * Useful helpers - file system access, date manipulation, simple XML 
> DOM access (for RSS display for example)
>
> 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.
>
> I'll try to post about the developer side of it tomorrow.
>
> Marc


-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga
Java Software Portal: http://opendoors.com

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

[<web...@st...>]

On Mon, 31 Mar 2003, Lane Sharman wrote:

| Hi Marc,
|
| This sounds good..

I second that..!

|
| I think my point that I have been trying to raise stems from the issue
| of the lure of having a really easy web app kit and then thinking you
| can do some things like consistent transactions with it out of the box.
| See google "Transaction ACID" for a general discussion on transaction
| consistency and how easy is to get it wrong in a multi-threaded env like
| a single servlet.
|
| 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".

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.

The following is a side-note to people that constantly whine that "it's
impossible to make a CMS":
  It IS possible to make a CMS! We (CoreTrek) actually have one!  ;)
It's in PHP. The idea is that articles are made up of "elements", e.g.
picture, textfield, single text-line, movie, "wysiwyg" text-element. Well,
sounds somewhat static, right?
  But how our developers have come about using this (I'm not on that
group, btw) is that they use the content of such elements as triggers on
the site.  So they develop the site, then tell the customer: if you put a
"1" in this field here (a single-line), then the background becomes green,
and if you put a "1" here, then the image is rotated 90 degrees, this date
here tells the system which day the bell shall ring, etc. In addition, a
article have a tag that tells which "render-page" that should be used to
show it.
  This means that the -editor- (the CMS) is pretty static (it has lots of
"add-on" modules that allow different pricing strategies, of course), but
the -websites- are developed with more logic (also in PHP), they aren't
simply a dumb display of the structure and articles in the CMS.

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..

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.

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.
Or, if the site was small enough, forget about all that, and just use the
first element, "template" to fetch template directly..

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

| >
| > 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..?

-- 
Mvh,
Endre Stølsvik               M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS         -  http://www.coretrek.com/
CoreTrek corporate portal / EIP -  http://www.corelets.com/

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