webmacro-devel — Discuss development issues related to the core of WebMacro

Re: [Webmacro-devel] WM WebApp design draft

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

>> Am I on the nail now?
>
> Yeah. You let the template author control the expert action flow. Not the 
> servlet writer. In this case, the action control flow is delegated to a 
> template writer's expert knowledge of the action flow, rule base. The 
> programmer writes the ugly stuff like transaction commits, etc.

OK, the only thing I don't like about this is using WM as a general purpose 
language. We don't have all the syntax and capabilities of a "full" 
language as well as the WM philosophy consideration that it's just for 
presentation.

Is this really necessary anyway? I mean, a template will expose links to a 
bunch of actions so the user clicks on them / submits forms. These will 
execute the appropriate action, and return the appropriate response.

Actions will be able to support some kind of "nextAction" parameter that 
indicates what should happen next after the Action executes.

i.e. an InsertIntoDatabaseAction might look for the nextAction parameter 
and use some supplied mechanism to execute that action after the insert. If 
the nextAction parameter is not present, it could just return a results 
template with the new database contents. (for example)

I can't see how the business rules of an application can be cleanly coded 
into a WM template (or main template plus included parts). Wouldn't it be 
really ugly?

One thing I am planning to add to the idea is a default helper for 
generating URIs to execute actions, so the template need not know the 
details of "hidden" parameter names and so on. This concept could be 
extended to support creating a single URI that will result in the execution 
of several actions i.e:

<FORM METHOD=POST ACTION="$WebMacro.executeActions( ["insertIntoDB", 
"commitToDB", "queryDB"])">
...hidden fields containing parameters such as table name and fields....
...visible data fields...
</FORM>

This function would make a pretty complex long URI, or put the info into 
the session and return a short URI that identifies the info in the session 
so the servlet can retrieve it and work out what actions to execute.

This would make things quite modular and allow actions to be stacked - 
writing to a DB and then emailing the data for example - with the proviso 
that all the info necessary to perform all actions must be available in the 
first request. We could allow per-action parameters to be supplied too:

<FORM METHOD=POST ACTION="$WebMacro.executeActions( 
["insertIntoDB:table=testdata", "commitToDB", "queryDB:sqlselect='SELECT * 
FROM testdata',template='dataresults.wmt'"])">

As every, thoughts welcome... but I really don't believe this webapp will 
be the cure for all web application needs... just enough for 90% of 
websites, and at the very least a much better replacement for server side 
includes and related technologies.

Marc

Re: [Webmacro-devel] WM WebApp design draft

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

On Mon, 20 Jan 2003 18:53:29 -0500, Eric B. Ridge <eb...@tc...> wrote:

>> A default implementation called SimpleHelperList would load a list of  
>> class names and their variable names from a properties file and would  
>> put them into the context. The properties file would be specified  using 
>> a servet context init parameter, or JNDI. Only one instance of  each 
>> would be created, and shared for all WebContext(s) used.
>
> I don't really see the difference between "helpers" and ContextTools.   
> This came up a few weeks ago too.  Should we just change the  ContextTool 
> loading to also be able instantiate *any* object with a  zero-arg ctor?  
> Should we use #bean instead of ContextTools and  "helpers"?  Lane says 
> they're all different, but they look like the  same thing to me.

Well helpers require no changes to webmacro.properties. i.e. the config is 
a no-brainer and down to the application.

The application, in this case "WM webapp", would load a list of these 
helper classnames and a name to bind them to from a simple properties file 
or JNDI. i.e. no knowledge of webmacro.properties naming conventions etc. 
and using JNDI (if possible) you get web-based config of these with some 
servlet containers.

#bean is not the same - #bean requires a bit more understanding of pages 
and contexts etc. to do it properly. I like the K.I.S.S. principle :)

I've used this exact mechanism in antwmcompile and Lane hasn't complained 
about it so far... the beauty of "helpers" is that one instance is created 
and passed to all contexts. If you want per-page stuff you can add a 
factory method to the helper or use #bean... or implement a different 
HelperList implementation.
 What I want to do is make it so that WM is a "shrink wrapped" part of this 
webapp - so  no new webmacro.properties are specified etc and it just ships 
with the defaults. Advanced users can extra the WAR and add a 
webmacro.properties if they need to override more complex stuff.

It's all about keeping the barrier to entry as low as possible. 
Antwmcompile, for example, can be used by anybody who can write HTML and 
run a script (batch file) to do the build. Apart from the WM scripting 
language being used, they are effectively unaware that WM is there.

>> 2. "Actions" are pluggable action handlers - a familiar concept to  
>> everyone here. However the way the servlet determines what action to  
>> execute is abstracted through ActionList. ActionList is always asked  
>> which Action to use for a given request (WebContext) so there is huge  
>> flexibility there. The default SimpleActionList will, like the  
>> SimpleHelperList, load a list of action classnames and their action  
>> "name" string, and will look for an "action=" parameter in the  request, 
>> and return the appropriate Action.
>
> Are actions .class files?  JavaScript (rhino rules!)?  WM  
> templates/#macro's?  Any of the above?

Well by default they are classes. As it is all abstracted, a custom 
ActionList could basically instantiate whatever it liked as long as it had 
an Action interface ... so you could defer to a javascript engine or 
whatever.

> PHP/ASP (and even JSP) take the old CGI approach where there is a 1:1  
> mapping between the URI and the script being executed.  Does this apply  
> here too?  Or are you thinking of something like:
> 	http://server.com/servlet/WMApp?template=search_results.wm
>
> instead of:
> 	http://server.com/search_results.wm

I'm pretty sure we can do both. It depends on your servlet container 
though.

> And what does this display?
> 	http://server.com/search_results.wm?template=logoff.wm

Again, should be fine if your servlet container supports it.

>> 3. "ActionResponse" represents what happens after an Action executes.  
>> It can trigger the return of a WM template to the client, or an error  
>> page containing an error message, or send a HTTP error code, or  
>> redirect to another URI. This gives Action implementations a great  deal 
>> of flexibility. The servlet handles how these actually take > place.
>
> Should #macro's be extended to allow return values?  Example:
>
> #macro getMyName () {
> #return "Eric"
> }
>
> #set $myName = #getMyName()
>
> Brian and Keats and I chatted about this a few times.  I don't think we  
> ever came to a good answer.
>
> If they could return values, they could act as Actions that #return an  
> $ActionResponse.
>
> I'm just thinking of (silly) ways to keep one from writing Java  classes. 
> One of those ideas is one I had awhile back for "WebMacro  Server Pages" 
> that went something like this:

I understand this... but we have to be cautious here because WM is not a 
general purpose language, and we should avoid using as one.

> --- search_results.wm --
>
> #script language="javascript" {
>
> 	Connection conn =  
> DriverManager.getConnection("jdbc:postgresql://server/ 
> db?user=postgres&password=postgres");
> 	Statement stmt = conn.createStatement("select * from books");
> ResultSst rs = stmt.executeQuery();
[snip]
> }
>
> --- / search_results.wm ---

I see what you're getting at, but YUCK. That's what WM was designed to 
avoid. Talk about WM ---> JSP convergence  
Noooooooooooooooooooooooooooooooo !

> The #script blocks would just be executed in-line as the template was  
> evaluated.  The "language" property could be any BSF compatible  language 
> (javascript, perl, python, whatever).  I mentioned this to  Brian once 
> and he said something like "uh, that breaks MVC".   :)    Nonetheless, 
> just throwing it out there as an idea.  You could  structure your script 
> snippets into little reusable blocks, wrap 'em in  #macro's, then do 
> something like:

I concur with Brian here. It's a horrible idea, in terms of WM's 
philosophy.

However, this BSF #script directive could be an optional directive.

I think the options for custom actions are pretty wide:

1. Write a simple Java class file. Trivial for java programmers. We can 
provide a tutorial about how to compile it all etc. After all, once you 
know how to create a .java file properly and compile it against the 
required libs, it's hardly different from writing javascript etc. - your 
code is just inside an existing method.

2. Use some of the many free Action implementations that will be available 
on the WM site - i.e. SendEmailAction, InsertIntoDatabaseAction, 
QueryDatabaseAction (using database connection from JNDI) and so on.

3. We could also make it so that templates could be used as actions too. 
This, coupled with the nasty #script idea would make it possible to do it 
all without writing Java code.

It's important to realise that I don't propose that this WM webapp be used 
for large-scale web applications. It is just aimed at people who want 
template-based sites with a bit more clever glue in them.

We have a fundamental problem putting any serious non-WM code/scripting 
into templates because of exception handling (or the lack thereof). 
Handling database exceptions cleanly when they happen during template 
processing is not fun. That's why I never do it... I always prepare data 
first, and that's what the Actions are supposed to do - but using something 
like templates with #script would likely provide a poor mechanism for 
handling such complicated error conditions cleanly.

Marc

Re: [Webmacro-devel] WM WebApp design draft

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

Marc Palmer wrote:

> On Mon, 20 Jan 2003 16:53:22 -0000, Marc Palmer <ma...@an...> 
> wrote:
>
>>> Second, I want to see some rule-based action handling from a template:
>>>
>>> #if (conditionA) { $actionA }
>>> .
>>> .
>>> .
>>> #if (conditionZ) { $actionB }
>>
>>
>> Hmmm, very interesting. Using templates as action handlers. 
>> Interesting plan. I will have to think about this more.
>
>
> Actually that's probably not what you meant is it. I suspect you meant 
> having a template that determines which action gets executed. If so, 
> this could be done with a custom ActionList implementation that loads 
> a single "actions.wm" template that provides all this logic, and it 
> evaluates this template every time getAction(WebContext) is called.
>
> Am I on the nail now? 

Yeah. You let the template author control the expert action flow. Not 
the servlet writer. In this case, the action control flow is delegated 
to a template writer's expert knowledge of the action flow, rule base. 
The programmer writes the ugly stuff like transaction commits, etc.

-Lane

>
>
> Marc
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>

-- 
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO

Re: [Webmacro-devel] WM WebApp design draft

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

I would like to see one of 2 things....

Marc Palmer wrote:

> On Mon, 20 Jan 2003 08:21:21 -0800, Lane Sharman <la...@op...> 
> wrote:
>
>> Marc,
>>
>> I would like to see 2 high level changes.
>>
>> First, all initialization, configuration is handled in a template 
>> that provides the application configurator with the ability to use 
>> templates to configure the application. property files are way to 
>> narrow and limiting.
>
>
> OK. This will be an interesting prospect. Do you mean all the stuff 
> that would normally be in webmacro.properties should be configurable 
> via a template/helper object? If so, there will no doubt be some 
> bootstrapping problems. i.e. WM needs to be running before this 
> template can be parsed, in which case it is too late to change things. 
> Perhaps it would have to bootstrap using a Broker init'd from 
> webmacro.properties, parse the config template, and then create a new 
> Broker using those settings. Dirty. 

webmacro.default stays as is. But, I believe we can introduce a new 
property in WebMacro.properties, "WebApp.StartupTemplateFile". With this 
property set to a default value, say, "StartupApplication.wm", the app 
jockey edits this file and follow some your protocols, features and 
capabilites at the current release point and enabled in this file. Much 
better than a properties file name=value.

The app jockey does any adding/changing/removing to enhance his WebApp. 
The WebApp base class, as part of its init(), will conform to the values 
left in the Context from the execution of StartupApplication.

>
>
>> Second, I want to see some rule-based action handling from a template:
>>
>> #if (conditionA) { $actionA }
>> .
>> .
>> .
>> #if (conditionZ) { $actionB }
>
>
> Hmmm, very interesting. Using templates as action handlers. 
> Interesting plan. I will have to think about this more. 

I really think we need to do something here.

#if ($UserWithoutCredentialAndSecureRequest) { $showGetCredentials}
#if ($UserWithCredentialAndHasPurchasedApp) {$showAppSupportPage}
.
. et al

-Lane

>
>
> Marc
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>

-- 
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO

Re: [Webmacro-devel] WM WebApp design draft

[Eric B. R. <eb...@tc...>]

On Sunday, January 19, 2003, at 11:41  AM, Marc Palmer wrote:
>
> Hi guys,
>
> Just spent a little time hacking out a rough design for how I see the  
> "install and go" WM WebApp working.
>
> Attached is a GIF of the basic UML. The buzzword here is "keep it  
> simple".

It does appear simple.

> Goals of the project:
>
> 1. Provide a web application that can be installed and used  
> immediately. No config necessary to start using simple WM templates -  
> web designers can use it immediately, including using #bean if they  
> want to.
>
> 2. Make it such that it is very flexible and can be used as a base for  
> custom web-applications written by Java programmers. i.e. "son of  
> WMServlet".
>
>
> The idea is as follows:
>
> 1. "Helpers" would be any Java classes/beans (no need to implement any  
> interface). These would be put into every context for every page  
> returned. The loading of the classnames and the instantiation of the  
> classes AND whether they are created on a per-context basis or use a  
> shared global instance is abstracted. Implementations of HelperList  
> will be able to do what they like.
>
> A default implementation called SimpleHelperList would load a list of  
> class names and their variable names from a properties file and would  
> put them into the context. The properties file would be specified  
> using a servet context init parameter, or JNDI. Only one instance of  
> each would be created, and shared for all WebContext(s) used.

I don't really see the difference between "helpers" and ContextTools.   
This came up a few weeks ago too.  Should we just change the  
ContextTool loading to also be able instantiate *any* object with a  
zero-arg ctor?  Should we use #bean instead of ContextTools and  
"helpers"?  Lane says they're all different, but they look like the  
same thing to me.

> 2. "Actions" are pluggable action handlers - a familiar concept to  
> everyone here. However the way the servlet determines what action to  
> execute is abstracted through ActionList. ActionList is always asked  
> which Action to use for a given request (WebContext) so there is huge  
> flexibility there. The default SimpleActionList will, like the  
> SimpleHelperList, load a list of action classnames and their action  
> "name" string, and will look for an "action=" parameter in the  
> request, and return the appropriate Action.
>
> Other implementations could make educated choices based on a wide  
> range of parameters or session variables, and Action(s) could even be  
> dynamically created on a per-request basis. This should also allow  
> this web application to plug in to existing web applications that may  
> wish to switch to a cleaner design model without changing any of their  
> templates or URIs. There need not be any 1:1 mapping between  
> parameters and Action executed, so in a way ActionList can become the  
> "brain" to a complex (or badly designed!) webapp.

Are actions .class files?  JavaScript (rhino rules!)?  WM  
templates/#macro's?  Any of the above?

PHP/ASP (and even JSP) take the old CGI approach where there is a 1:1  
mapping between the URI and the script being executed.  Does this apply  
here too?  Or are you thinking of something like:
	http://server.com/servlet/WMApp?template=search_results.wm

instead of:
	http://server.com/search_results.wm

And what does this display?
  	http://server.com/search_results.wm?template=logoff.wm


>
> 3. "ActionResponse" represents what happens after an Action executes.  
> It can trigger the return of a WM template to the client, or an error  
> page containing an error message, or send a HTTP error code, or  
> redirect to another URI. This gives Action implementations a great  
> deal of flexibility. The servlet handles how these actually take > place.

Should #macro's be extended to allow return values?  Example:

#macro getMyName () {
      #return "Eric"
}

#set $myName = #getMyName()

Brian and Keats and I chatted about this a few times.  I don't think we  
ever came to a good answer.

If they could return values, they could act as Actions that #return an  
$ActionResponse.

I'm just thinking of (silly) ways to keep one from writing Java  
classes.  One of those ideas is one I had awhile back for "WebMacro  
Server Pages" that went something like this:

--- search_results.wm --

#script language="javascript" {

	Connection conn =  
DriverManager.getConnection("jdbc:postgresql://server/ 
db?user=postgres&password=postgres");
	Statement stmt = conn.createStatement("select * from books");
          ResultSst rs = stmt.executeQuery();

          rs.last();
          int row_cnt = rs.getRow();
          rs.first();

          context.put ("Results", new WMRSWrapper(rs));
          context.put ("RowCount", row_cnt);
}

Found $RowCount records:
#count $idx from 1 to $RowCount {
        $Results.absolute($idx)
        <li>$idx.  $Results.Title, $Results.Author $Results.ISBN
}

#script language="javascript" {
  	rs.close();
          stmt.close();
}

--- / search_results.wm ---

The #script blocks would just be executed in-line as the template was  
evaluated.  The "language" property could be any BSF compatible  
language (javascript, perl, python, whatever).  I mentioned this to  
Brian once and he said something like "uh, that breaks MVC".   :)    
Nonetheless, just throwing it out there as an idea.  You could  
structure your script snippets into little reusable blocks, wrap 'em in  
#macro's, then do something like:

--- search_results.wm --
#include as macro "jdbc.macros"
#include as template "globals.beans"

## stuffs $RowCount and $Results into context
#openQuery($JDBCURL, $GetAllBooksQuery)

Found $RowCount records:
#count $idx from 1 to $RowCount {
        #gotoRow($idx)
        <li>$idx.  $Results.Title, $Results.Author $Results.ISBN
}

#closeQuery()

--- / search_results.wm ---

eric

Re: [Webmacro-devel] WM WebApp design draft

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

Marc,

I would like to see 2 high level changes.

First, all initialization, configuration is handled in a template that 
provides the application configurator with the ability to use templates 
to configure the application. property files are way to narrow and limiting.

Second, I want to see some rule-based action handling from a template:

#if (conditionA) { $actionA }
.
.
.
#if (conditionZ) { $actionB }

-Lane

Marc Palmer wrote:

>
> Hi guys,
>
> Just spent a little time hacking out a rough design for how I see the 
> "install and go" WM WebApp working.
>
> Attached is a GIF of the basic UML. The buzzword here is "keep it 
> simple".
>
> Goals of the project:
>
> 1. Provide a web application that can be installed and used 
> immediately. No config necessary to start using simple WM templates - 
> web designers can use it immediately, including using #bean if they 
> want to.
>
> 2. Make it such that it is very flexible and can be used as a base for 
> custom web-applications written by Java programmers. i.e. "son of 
> WMServlet".
>
>
> The idea is as follows:
>
> 1. "Helpers" would be any Java classes/beans (no need to implement any 
> interface). These would be put into every context for every page 
> returned. The loading of the classnames and the instantiation of the 
> classes AND whether they are created on a per-context basis or use a 
> shared global instance is abstracted. Implementations of HelperList 
> will be able to do what they like.
>
> A default implementation called SimpleHelperList would load a list of 
> class names and their variable names from a properties file and would 
> put them into the context. The properties file would be specified 
> using a servet context init parameter, or JNDI. Only one instance of 
> each would be created, and shared for all WebContext(s) used.
>
> 2. "Actions" are pluggable action handlers - a familiar concept to 
> everyone here. However the way the servlet determines what action to 
> execute is abstracted through ActionList. ActionList is always asked 
> which Action to use for a given request (WebContext) so there is huge 
> flexibility there. The default SimpleActionList will, like the 
> SimpleHelperList, load a list of action classnames and their action 
> "name" string, and will look for an "action=" parameter in the 
> request, and return the appropriate Action.
>
> Other implementations could make educated choices based on a wide 
> range of parameters or session variables, and Action(s) could even be 
> dynamically created on a per-request basis. This should also allow 
> this web application to plug in to existing web applications that may 
> wish to switch to a cleaner design model without changing any of their 
> templates or URIs. There need not be any 1:1 mapping between 
> parameters and Action executed, so in a way ActionList can become the 
> "brain" to a complex (or badly designed!) webapp.
>
> 3. "ActionResponse" represents what happens after an Action executes. 
> It can trigger the return of a WM template to the client, or an error 
> page containing an error message, or send a HTTP error code, or 
> redirect to another URI. This gives Action implementations a great 
> deal of flexibility. The servlet handles how these actually take place.
>
> 4. By default, if no action is found the system will return to 
> executing the ReturnTemplateAction which looks for a "template=" 
> parameter and tries to return that template. This would be the most 
> common usage for "Joe web monkey", as it would require no Java code or 
> configuration.
>
> 5. All of the core behaviour in the servlet uses protected methods so 
> that it can just be used as a framework for more complicated 
> applications or people who don't want to use the HelperList or 
> ActionList.
>
> As you can see it's all pretty simple I think, and should be trivial 
> to implement.
>
> Comments please! I do feel pretty strongly though that this should be 
> so simple that any idiot can understand it (even Java newbies) and 
> write helpers and custom actions.
>
> Anyway, using this web app along with #macro, #bean etc. I think WM 
> could definitely be a contender for the "webmaster scripting" market 
> occupied by PHP and ASP.
>
>
> ------------------------------------------------------------------------
>

-- 
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO

Re: [Webmacro-devel] WM WebApp design draft

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

On Mon, 20 Jan 2003 16:53:22 -0000, Marc Palmer <ma...@an...> wrote:

>> Second, I want to see some rule-based action handling from a template:
>>
>> #if (conditionA) { $actionA }
>> .
>> .
>> .
>> #if (conditionZ) { $actionB }
>
> Hmmm, very interesting. Using templates as action handlers. Interesting 
> plan. I will have to think about this more.

Actually that's probably not what you meant is it. I suspect you meant 
having a template that determines which action gets executed. If so, this 
could be done with a custom ActionList implementation that loads a single 
"actions.wm" template that provides all this logic, and it evaluates this 
template every time getAction(WebContext) is called.

Am I on the nail now?

Marc

Re: [Webmacro-devel] WM WebApp design draft

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

On Mon, 20 Jan 2003 08:21:21 -0800, Lane Sharman <la...@op...> 
wrote:

> Marc,
>
> I would like to see 2 high level changes.
>
> First, all initialization, configuration is handled in a template that 
> provides the application configurator with the ability to use templates 
> to configure the application. property files are way to narrow and 
> limiting.

OK. This will be an interesting prospect. Do you mean all the stuff that 
would normally be in webmacro.properties should be configurable via a 
template/helper object? If so, there will no doubt be some bootstrapping 
problems. i.e. WM needs to be running before this template can be parsed, 
in which case it is too late to change things. Perhaps it would have to 
bootstrap using a Broker init'd from webmacro.properties, parse the config 
template, and then create a new Broker using those settings. Dirty.

> Second, I want to see some rule-based action handling from a template:
>
> #if (conditionA) { $actionA }
> .
> .
> .
> #if (conditionZ) { $actionB }

Hmmm, very interesting. Using templates as action handlers. Interesting 
plan. I will have to think about this more.

Marc

Re: [Webmacro-devel] Bad interaction with TimeLoop and cache time s?

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

>
>
>If they couldn't have done this, what use would there be for computers in
>the first place? I don't find this topic amazing or any problematic, Lane.
>I'm just asking whether anyone on this forum have any more info on how
>your cache would operate on a _NON-TIGHTLY_ coupled memory system. Which
>was my question. ..and was what Brian pointet out.
>
all bets are off on loosely-coupled systems. I discussed tightly coupled 
systems only. I do not have any hands-on engineering experience 
w/loosely coupled, shared memory systems.

-L

Re: [Webmacro-devel] Next Version of WM?

[Eric B. R. <eb...@tc...>]

On Monday, January 20, 2003, at 10:46  AM, Marc Palmer wrote:

> On Mon, 20 Jan 2003 10:23:38 -0500, Eric B. Ridge <eb...@tc...> wrote:
>
>> What should the version number be of the next version? 1.2?  2.0?
>
> Hmm, 2.0 sounds nice if there's a significant change in there.

Or just to 1-up Velocity...  *grin*

> Dunno about that... and I don't mean to harp on but isn't anyone else 
> excited by the prospect of a WM webapp that every schmuck in the world 
> can use without understanding Java? I would have thought this is the 
> killer app for WM, though not necessarily of huge interest to WM 
> developers - it's a simple thing for us to do, call it "marketing 
> collateral".

Maybe this should be discussed on the -user list?  I agree it's 
something we should do.

eric

Re: [Webmacro-devel] Next Version of WM?

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

On Mon, 20 Jan 2003 10:23:38 -0500, Eric B. Ridge <eb...@tc...> wrote:

> What should the version number be of the next version? 1.2?  2.0?

Hmm, 2.0 sounds nice if there's a significant change in there.

> What do plan on doing for it?  I can think of:
>
> 1) fix PropertyOperatorCache to handle exceptions in such a way that 
> context information ($variable names) can always be determined
> 2) more core #macros
> 3) global macro files/repository via WebMacro.properties
> 4) bugs on bugzilla
>
> Is there room for optimization anywhere?

Dunno about that... and I don't mean to harp on but isn't anyone else 
excited by the prospect of a WM webapp that every schmuck in the world can 
use without understanding Java? I would have thought this is the killer app 
for WM, though not necessarily of huge interest to WM developers - it's a 
simple thing for us to do, call it "marketing collateral".

I definitely want feedback on this idea - even if some people think it's a 
waste of time. Personally I see WM only getting a dozen or so downloads per 
day under normal circumstances, which seems far too few for such a useful 
product.

Marc

[Webmacro-devel] Next Version of WM?

[Eric B. R. <eb...@tc...>]

What should the version number be of the next version? 1.2?  2.0?

What do plan on doing for it?  I can think of:

1) fix PropertyOperatorCache to handle exceptions in such a way that 
context information ($variable names) can always be determined
2) more core #macros
3) global macro files/repository via WebMacro.properties
4) bugs on bugzilla

Is there room for optimization anywhere?

eric

Re: [Webmacro-devel] WM WebApp design draft

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

> In the normal url's (between web page's) we have used &lang= etc. without 
> problems.
> I have asked a few colleage's if they knew the problem from last year.
>
> They didn't knew the &action= problem but they did knew the &lang= 
> problem!
> The solution is to use &lng= or something else instead.
>
> I don't know if it is a W3C standard or just a bug in a lot of mail 
> programs.

I had a look at the W3C docs I could find on this and it looks like it is a 
bug in the HTML parser of the mail programs.

As far as I can see there is no specification that reserves any query 
parameters in URIs. The lang= attribute in HTML is part of the HTML 
standard so this must be where email clients are getting confused.

I found no mention at all of action=

Marc

Re: [Webmacro-devel] Bad interaction with TimeLoop and cache time s?

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

On Fri, 17 Jan 2003, Lane Sharman wrote:

| In short, in tightly coupled, shared memory systems, the OS kernel does
| not let you "roll back the clock" to some previous, and corrupt state to
| read shared memory. It just does not do this. This is at the kernel, not
| the JVM level. If processor A is executing  thread (A1) and processor B
| is executing thread (B1) in an MP setting, the register and page cache
| will be shared such that images are ACIDic (Atomic, Consistent,
| Isolated).

This is at the JVM level. The OS is an operating system, and does not
dictate how you use your processors and memory, e.g. threading and synch
and memory barriers in C. The problems are the _caches_ of memory, not the
memory, which copies and duplicates parts of the main memory. On e.g. a PC
with 4 intel processors, the caches are controlled by 'cache-coherency'
_hardwired_ protocol called MESI (Modified-Exclusive-Shared-Invalid) *),
ensuring thight memory consistency, allowing the programmer to imagine
that it is a uni-processor memory he's developing on. However, in a cray,
I believe, the processors are sitting like small computers themselves,
having their own little memory, which is mapped like a cache onto the huge
main memory, and there is explicit machine-level instructions that flushes
memory, "memory barriers", with _no_ automatic synchronization of the
caches or "own-memory" parts. The same would go for e.g. a linuxcluster
operating like a single machine; there is no reason why a JVM shouldn't be
able to run on the _complete_ machine, with its different threads being
started on different machines.  The memory specification of Java, as I've
learned, actually allows such loose models, because of its very explicit
synchronization specifications. Of course, synched blocks would certainly
take a long time, and should be avoided at more or less all costs.

It is a this point I'm asking how the sematics of the synch-blocks
actually are, and what the volatile keyword _actually_ does. Your cache
_could not_ run on my imaginary Linux superboxen w/o the synch issues
detailed worked out.

| With this kind of engineering at the kernel of the OS, highly
| transactional, shared memory systems like banking and flight reservation
| systems have been working for about 25 years+.

If they couldn't have done this, what use would there be for computers in
the first place? I don't find this topic amazing or any problematic, Lane.
I'm just asking whether anyone on this forum have any more info on how
your cache would operate on a _NON-TIGHTLY_ coupled memory system. Which
was my question. ..and was what Brian pointet out.


*) Check out e.g.
   http://www.aceshardware.com/Spades/read.php?article_id=30000187

|
| -Lane
|
| Endre Stølsvik wrote:
|
| >On Thu, 16 Jan 2003, Brian Goetz wrote:
| >
| >| > because the cache is immutable and therefore can be used unsynchronized.
| >|
| >| ... on uni-processor systems, or on multi-processor systems that have
| >| a stronger memory model than the JLS requires, which would include Intel,
| >| but not PPC, Alpha, or some configurations of Sparc ...
| >
| >This I have also always though about: you _cannot_ go about being
| >unsynchronized "all the time" on such non-cache-synched systems, thus
| >probably raising problems for Lane's cache.
| >
| >HOWEVER, isn't entering a synchronized block actually committing
| >_everything_ of that thread's unflushed cache back to memory (and
| >invalidating it)? So that, if this is in a servlet, then you _would_ have
| >had some synchronized blocks around some other part of the system/engine.
| >Wouldn't this also have changed the reference to the "unsynched" map of
| >Lane? - The system works by having one unsynched map, and one synched "for
| >backup".  Then, after some time, the synched map is remade to be a
| >unsynched map, and then put in place of the existing unsynched map. The
| >problem is of course that this won't propagate to the 'other processors'
| >on the system..
| >
| >Well..
| >
| >If the synch-semantics require _all_ cache to be flushed back to main
| >memory, wouldn't this _eventually_ propagate to the other processors, in a
| >consistent way, with e.g. the next HttpSession lookup by the servlet
| >container?
| >
| >If not, what if the reference to the synched map is declared 'volatile'?
| >Would that change anything? What happens to the objects in the map? Would
| >you actuall be able to get hold of memory areas that weren't initialized,
| >as the other thread would have freed some parts of his view of the memory
| >(e.g. freeing the synched map), and then allocated some (and overlapping)
| >parts of the memory to the new map (which he puts to the volatile
| >reference).. ?
| >
| >If those questions just sounds stupid, I must have phrased myself wrongly,
| >because they aren't stupid! No-one has answered them satisfactory yet! ;)
| >I would love if for example you, Brian, gave it a shot!
| >
| >
| >
| >
|
|

-- 
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] WM WebApp design draft

[Mike W. <m.w...@tr...>]

At 12:15 1/20/2003, you wrote:
>On Mon, 20 Jan 2003 08:20:11 +0100, Mike Weerdenburg 
><m.w...@tr...> wrote:
>
>>Sounds good, but please be carefull!
>>&action=
>>&lang=
>>seems to be reserved words in HTML-land...
>>
>>Don't try to use these in an URL, because some browser versions/email 
>>programs cut off the rest of the url (after action or lang).
>>
>>We have had troubles with this about a year ago...
>
>That's bizarre. I've never heard of any "reserved" query parameters in any 
>W3C standards. That's very crap indeed.
>
>Can anyone provide any more detailed info on this? I'll have a look around 
>myself. I've used action= in web applications to date with no problems at 
>all, but we weren't mailing links to people.


In the normal url's (between web page's) we have used &lang= etc. without 
problems.
I have asked a few colleage's if they knew the problem from last year.

They didn't knew the &action= problem but they did knew the &lang= problem!
The solution is to use &lng= or something else instead.

I don't know if it is a W3C standard or just a bug in a lot of mail programs.

Mike Weerdenburg.

>--
>Marc Palmer
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
>are you planning your Web Server Security? Click here to get a FREE
>Thawte SSL guide and find the answers to all your  SSL security issues.
>http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>---
>[this e-mail is scanned for viruses by www.traction-it.nl]
>


---
[this e-mail is scanned for viruses by www.traction-it.nl]

Re: [Webmacro-devel] WM WebApp design draft

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

On Mon, 20 Jan 2003 08:20:11 +0100, Mike Weerdenburg 
<m.w...@tr...> wrote:

> Sounds good, but please be carefull!
> &action=
> &lang=
> seems to be reserved words in HTML-land...
>
> Don't try to use these in an URL, because some browser versions/email 
> programs cut off the rest of the url (after action or lang).
>
> We have had troubles with this about a year ago...

That's bizarre. I've never heard of any "reserved" query parameters in any 
W3C standards. That's very crap indeed.

Can anyone provide any more detailed info on this? I'll have a look around 
myself. I've used action= in web applications to date with no problems at 
all, but we weren't mailing links to people.
-- 
Marc Palmer

Re: [Webmacro-devel] WM WebApp design draft

[Mike W. <m.w...@tr...>]

At 17:41 1/19/2003, you wrote:
>2. "Actions" are pluggable action handlers - a familiar concept to 
>everyone here. However the way the servlet determines what action to 
>execute is abstracted through ActionList. ActionList is always asked which 
>Action to use for a given request (WebContext) so there is huge 
>flexibility there. The default SimpleActionList will, like the 
>SimpleHelperList, load a list of action classnames and their action "name" 
>string, and will look for an "action=" parameter in the request, and 
>return the appropriate Action.

Sounds good, but please be carefull!
&action=
&lang=
seems to be reserved words in HTML-land...

Don't try to use these in an URL, because some browser versions/email 
programs cut off the rest of the url (after action or lang).

We have had troubles with this about a year ago...

We sended out a mailing using webmacro, with a link to unsubscribe from the 
database.
e.g.
http://www.traction-it.nl/prg/wmmail?firm=MyTest&lang=NL&action=unsubscribe

What hapened was the following:

We got back a lot of error messages in the log files, after examining the 
hits we saw the error's came from the following links:
http://www.traction-it.nl/prg/wmmail?firm=MyTest&lang=
http://www.traction-it.nl/prg/wmmail?firm=MyTest&lang=NL&action=
A lot of client browsers/email programs didn't send the rest of the url...

It could be that this problems don't occur anymore, but I thought I could 
better trow it in the group before WM WebApp is up and running.

<snip from W3 org>
Specifying the language of content: the lang attribute
Attribute definitions
lang = language-code
Specifies the primary language of an element's text content. The value of 
this attribute is a language code as specified by [RFC1766]. Please consult 
this document for authoritative information on language codes. Whitespace 
is not allowed within the language-code. All language-codes are 
case-insensitive. The default language is "unknown".
</snip from W3 org>


Greetings from the Netherlands,
a webmacro user for about 4+ years.

Mike Weerdenburg - Development
Traction Information Technologies
Bedrijvenweg 6a
1424 PX De Kwakel
T: 0297 - 386 850
F: 0297 - 386 851

Re: [Webmacro-devel] WM WebApp design draft

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

> 4. By default, if no action is found the system will return to executing 
> the ReturnTemplateAction which looks for a "template=" parameter and 
> tries to return that template. This would be the most common usage for 
> "Joe web monkey", as it would require no Java code or configuration.

Of course, this would also happen if the servlet receives a request for a 
file URI with a .wmt or similar extension, so 
http://yourserver.com/webmacro/mytemplate.wmt would return a parsed 
template.

Marc

[Webmacro-devel] WM WebApp design draft

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

Hi guys,

Just spent a little time hacking out a rough design for how I see the 
"install and go" WM WebApp working.

Attached is a GIF of the basic UML. The buzzword here is "keep it simple".

Goals of the project:

1. Provide a web application that can be installed and used immediately. No 
config necessary to start using simple WM templates - web designers can use 
it immediately, including using #bean if they want to.

2. Make it such that it is very flexible and can be used as a base for 
custom web-applications written by Java programmers. i.e. "son of 
WMServlet".


The idea is as follows:

1. "Helpers" would be any Java classes/beans (no need to implement any 
interface). These would be put into every context for every page returned. 
The loading of the classnames and the instantiation of the classes AND 
whether they are created on a per-context basis or use a shared global 
instance is abstracted. Implementations of HelperList will be able to do 
what they like.

A default implementation called SimpleHelperList would load a list of class 
names and their variable names from a properties file and would put them 
into the context. The properties file would be specified using a servet 
context init parameter, or JNDI. Only one instance of each would be 
created, and shared for all WebContext(s) used.

2. "Actions" are pluggable action handlers - a familiar concept to everyone 
here. However the way the servlet determines what action to execute is 
abstracted through ActionList. ActionList is always asked which Action to 
use for a given request (WebContext) so there is huge flexibility there. 
The default SimpleActionList will, like the SimpleHelperList, load a list 
of action classnames and their action "name" string, and will look for an 
"action=" parameter in the request, and return the appropriate Action.

Other implementations could make educated choices based on a wide range of 
parameters or session variables, and Action(s) could even be dynamically 
created on a per-request basis. This should also allow this web application 
to plug in to existing web applications that may wish to switch to a 
cleaner design model without changing any of their templates or URIs. There 
need not be any 1:1 mapping between parameters and Action executed, so in a 
way ActionList can become the "brain" to a complex (or badly designed!) 
webapp.

3. "ActionResponse" represents what happens after an Action executes. It 
can trigger the return of a WM template to the client, or an error page 
containing an error message, or send a HTTP error code, or redirect to 
another URI. This gives Action implementations a great deal of flexibility. 
The servlet handles how these actually take place.

4. By default, if no action is found the system will return to executing 
the ReturnTemplateAction which looks for a "template=" parameter and tries 
to return that template. This would be the most common usage for "Joe web 
monkey", as it would require no Java code or configuration.

5. All of the core behaviour in the servlet uses protected methods so that 
it can just be used as a framework for more complicated applications or 
people who don't want to use the HelperList or ActionList.

As you can see it's all pretty simple I think, and should be trivial to 
implement.

Comments please! I do feel pretty strongly though that this should be so 
simple that any idiot can understand it (even Java newbies) and write 
helpers and custom actions.

Anyway, using this web app along with #macro, #bean etc. I think WM could 
definitely be a contender for the "webmaster scripting" market occupied by 
PHP and ASP.

-- 
Marc Palmer

Re: [Webmacro-devel] Bad interaction with TimeLoop and cache time s?

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

Hi Endre,

Out of college, many epochs ago, I wrote the tightly coupled, symettric=20
CPU scheduler/dispatch kernel for a large MP mainframe which had an=20
underlying VM architecture. All in a high level assembler :).

In such an architecture, where you have a shared memory among N=20
processors, there is a well-known lock called the MP lock. This lock=20
allows one and only processor to run. This lock is employed to resolve=20
page traps in the kernel and the user space which, when not used, would=20
give rise to an faulty and corrupt page image. (Reading a page while its=20
phsyical value was being updated by the page IO module). It also flushes=20
indovidual processor registers.

I do not like to debate this topic any longer as I have mentioned in the=20
past.

In short, in tightly coupled, shared memory systems, the OS kernel does=20
not let you "roll back the clock" to some previous, and corrupt state to=20
read shared memory. It just does not do this. This is at the kernel, not=20
the JVM level. If processor A is executing  thread (A1) and processor B=20
is executing thread (B1) in an MP setting, the register and page cache=20
will be shared such that images are ACIDic (Atomic, Consistent,=20
Isolated). With this kind of engineering at the kernel of the OS, highly=20
transactional, shared memory systems like banking and flight reservation=20
systems have been working for about 25 years+.

-Lane

Endre St=F8lsvik wrote:

>On Thu, 16 Jan 2003, Brian Goetz wrote:
>
>| > because the cache is immutable and therefore can be used unsynchroni=
zed.
>|
>| ... on uni-processor systems, or on multi-processor systems that have
>| a stronger memory model than the JLS requires, which would include Int=
el,
>| but not PPC, Alpha, or some configurations of Sparc ...
>
>This I have also always though about: you _cannot_ go about being
>unsynchronized "all the time" on such non-cache-synched systems, thus
>probably raising problems for Lane's cache.
>
>HOWEVER, isn't entering a synchronized block actually committing
>_everything_ of that thread's unflushed cache back to memory (and
>invalidating it)? So that, if this is in a servlet, then you _would_ hav=
e
>had some synchronized blocks around some other part of the system/engine.
>Wouldn't this also have changed the reference to the "unsynched" map of
>Lane? - The system works by having one unsynched map, and one synched "f=
or
>backup".  Then, after some time, the synched map is remade to be a
>unsynched map, and then put in place of the existing unsynched map. The
>problem is of course that this won't propagate to the 'other processors'
>on the system..
>
>Well..
>
>If the synch-semantics require _all_ cache to be flushed back to main
>memory, wouldn't this _eventually_ propagate to the other processors, in=
 a
>consistent way, with e.g. the next HttpSession lookup by the servlet
>container?
>
>If not, what if the reference to the synched map is declared 'volatile'?
>Would that change anything? What happens to the objects in the map? Woul=
d
>you actuall be able to get hold of memory areas that weren't initialized=
,
>as the other thread would have freed some parts of his view of the memor=
y
>(e.g. freeing the synched map), and then allocated some (and overlapping=
)
>parts of the memory to the new map (which he puts to the volatile
>reference).. ?
>
>If those questions just sounds stupid, I must have phrased myself wrongl=
y,
>because they aren't stupid! No-one has answered them satisfactory yet! ;=
)
>I would love if for example you, Brian, gave it a shot!
>
>
> =20
>

--=20
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO

Re: [Webmacro-devel] SF stats up, sort of

[Eric B. R. <eb...@tc...>]

On Friday, January 17, 2003, at 11:22  AM, Marc Palmer wrote:

> On Fri,
>> The most hits we've had (since May 02, 2002):
>> 	95413 16/May/2002
>>
>> I wonder what happened on that day.
>
> Christ, that is nuts. Are you sure your server wasn't hijacked and 
> used as a warez repository for a day or so?

ha!  nope.

> Maybe someone wrote an automated test script running against 
> www.webmacro.org ... it would be interesting to find out what the 
> UserAgent and referrers were on that day.

That or they broke their "Refresh" button.  If you want user agents and 
referrers I can do that too.

>
> All in all though, I'm impressed at getting the hits up to 14000 in 
> one day. That's an increase of around 10,000 over normal daily 
> accesses.

it would be nice to sustain 14k/day every day.

eric

>
> Marc
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts 
> will
> allow you to extend the highest allowed 128 bit encryption to all your 
> clients even if they use browsers that are limited to 40 bit 
> encryption. Get a guide 
> here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] SF stats up, sort of

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

On Fri,
> The most hits we've had (since May 02, 2002):
> 	95413 16/May/2002
>
> I wonder what happened on that day.

Christ, that is nuts. Are you sure your server wasn't hijacked and used as 
a warez repository for a day or so?

Maybe someone wrote an automated test script running against 
www.webmacro.org ... it would be interesting to find out what the UserAgent 
and referrers were on that day.

All in all though, I'm impressed at getting the hits up to 14000 in one 
day. That's an increase of around 10,000 over normal daily accesses.

Marc

Re: [Webmacro-devel] SF stats up, sort of

[Eric B. R. <eb...@tc...>]

On Friday, January 17, 2003, at 06:54  AM, Marc Palmer wrote:
>
> Eric - can we "grep -c" access_log on webmacro.org to get the download 
> stats for the last few days? Without a log analyser it's going to be a 
> tricky regex to stats per day though.

you just want a count of page hits per day since the PR?  No problem:

% cut -d- -f3 access_log | cut -d\[ -f2 | cut -d: -f1 | uniq -c
...
3970 01/Jan/2003
3773 02/Jan/2003
4047 03/Jan/2003
2582 04/Jan/2003
3130 05/Jan/2003
3399 06/Jan/2003
3422 07/Jan/2003
3474 08/Jan/2003
3789 09/Jan/2003
2217 10/Jan/2003
  861 12/Jan/2003
4301 13/Jan/2003
6772 14/Jan/2003
14189 15/Jan/2003
8462 16/Jan/2003
4081 17/Jan/2003

Note that the server was offline for part of the 10th thru part of the 
12th.

The most hits we've had (since May 02, 2002):
	95413 16/May/2002

I wonder what happened on that day.

eric

Re: [Webmacro-devel] WM download page

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

>> Now 1.1 is out why offer a beta?
>
> So the beta releases should be removed from the SF download page *and* 
> unlinked from www.webmacro.org?

Hmm I see. Not sure. What does everyone else think? I suppose both links on 
the WM site just link to the SF download page. In which case, there should 
be only one link anyway on WM.org ...

Don't think we need to remove betas from SF though... although it's 
questionable what their worth is once there is a final release.

Marc

Re: [Webmacro-devel] WM download page

[Eric B. R. <eb...@tc...>]

On Friday, January 17, 2003, at 07:13  AM, Marc Palmer wrote:

>
> Eric (or whoever) ... shouldn't we remove the 1.1b3 download links 
> from the WM.org download page? This will probably confuse people 
> (download stats for b3 from the WM site will confirm/debunk this).

The WM site (www.webmacro.org) doesn't (and can't) track download 
statistics b/c all downloads are now done via SF.

>
> Now 1.1 is out why offer a beta?

So the beta releases should be removed from the SF download page *and* 
unlinked from www.webmacro.org?

eric

>
> -- 
> Marc Palmer
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com
> Understand how to protect your customers personal information by 
> implementing
> SSL on your Apache Web Server. Click here to get our FREE Thawte 
> Apache Guide: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel