From: Eric B. R. <eb...@tc...> - 2003-01-20 23:56:10
|
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 |