--- "Sherlock, Ric" <[EMAIL PROTECTED]> wrote: > Yes, I tried redirection successfully, but I think I prefer transfer for > this usage.
It would be good to have redirect verb too. There are a number of ways it could be done: - <meta http-equiv="refresh ..> HTML - Refresh: 0; url=http://www.example.com/ HTTP header http://en.wikipedia.org/wiki/URL_redirection - Location/Status CGI headers http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html > > Another way is instead of 3 pages have two: > > one login page, and the other main logged-in page with > > ... > > <% load 'script.ijs' %> > > <% if. -.loggedIn'' do. transfer 'login.html' end. %> > > ... rest of the page > > Yes that would clean up the number of pages and may make the app easier > to follow, but starts to mix up the "application logic" and the display. > > > 'Firstname Lastname'=: getUserInfo ".uid > > > > Another way is to do it in the target JHP page, rather than > > sharing it between two code entities. > > Agreed, but again that would mix the logic & display components of the > application more? > It needs to be determined in a wider view how would this separation between logic and presentation look like. In this context, it looks like navigation logic, and your attempt of a third driver-script is to provide such navigation logic. But as driver it's better to be hidden whereas it is the target of a URL. In is a virtual URL pattern, the way Wiki, Rails, WebObjects, Struts, etc. work, part of URL represents object path/action and with state it determines code to be executed. In classic JHP, it is more traditional what-you-navigate-is-what-you-get: URLs are mapped to actual files in JHP application folder. However, event-driven navigation logic would still be possible, for example, by defining a navigation delegate on the level of JHP configuration; possibly as a onBeginRequest handler in an equivalent of Global.asp[x], i.e. an Application object. Using "load 'script.ijs'" is just an explicit way to invoke such common definitions. There could be an automatic mechanism to invoke page- related code, e.g. if page.jhp is navigated and page.ijs exists, then it is evaluated first; further if global.ijs exists in the target folder, it is invoked yet before that, etc. Using this convention, most of the code except "binding" value injection can be "hidden" in code-behind files. However, what is suggested for login logic is quite an interesting idea: it can be thought of as "Markup-Behind". It preserves the .html files for compatibility with HTML designer apps and puts .jhp handlers up front as URL targets to be picked up by web server configured handler. Thus it can also be called "Code-Upfront". It has a few advantages: - natirally puts code processing before markup rendering - can provide multiple alternative markups for same entry code - prepares business values for thin binding with markup > > It's good to have a few alternatives for passing control > > between pages: > > - transfer: abandon current > > - execute: resume current > > - redirect: send new URL for client refresh > > > > It would be good for them to understand relative paths as > > well as '~CGI/' based paths and map to correct URL or physical path. > > For any non-JHP file they would just > > > > ContentType mimeForFile file NB. runs once > > stdout fread file > > I will have a go at coding a transfer control verb, but I'm not sure I > understand enough about the URL/physical path mapping functionality you > describe to get that in there yet. I believe 3 types of locations is enough: - absolute URL (refresh 'http://www.jsoftware.com'), only for Refresh - relative (refresh 'login.html'), for Refresh as is, for Transfer mapped to physical - jpath to physical (transfer '~CGI/login.html'), for Transfer > How would mimeForFile determine the mime type of a file? Or would that > just be a lookup? I would have a look at Location/Status CGI output headers (see reference above): maybe the web server will take care of that by either invoking a new instance of JHP handler or sending the other static resource taking care of mime, etc. > > > coming straight from say Dreamweaver, they won't have '<%' as the > > > first > > > > HTML editors should support <% %>. However, maybe not as > > first character--for this reason, should jhp recognize markup > > as '<' rather than '<%'? Or even ('<%' +./@E. ]) ? > > You're right that the html file could have '<% %>' at the start of the > file and would be interpreted fine by the HTML editor, however it seems > kind of icky! The first option ('<') would process all html files, > whether they contain code or not? Would the last option be safe for > files that might contain '<%' in the text somewhere? They are not just HTML file--they have extension .jhp. We need just to distinguish JHP with markup for templates and JHP as script evaluated as is. ('<%' +./@E. ]) won't work because '<%' can occurr in non-markup script-type JHP. Another purpose of initial '<%' is to ensure ContentType--a required Header. ____________________________________________________________________________________ Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
