Thanks for your thoughts.
> [mailto:[EMAIL PROTECTED] On Behalf Of Oleg Kobchenko
> This is a typical logged-in/not-logged-in dual view.
> It is common to make the not-logged-in view a login screen
> with user ID/password. The same page is a destination for
> logout with a logout message.
> The message feature is also used for unsuccessful login attempt.
Yes that's my intention, but was just really demoing what I now
understand from your reply to be the Transfer method.
> It's good to think about the logged-in/not-logged-in feature
> as a switch that represents two views, as a markup control:
>
> <% if. loggedIn'' do.
> transfer 'loggedIn.jhp'
> else.
> transfer 'login.html'
> end. %>
>
> Where the logic of loggedIn verb is hidden somewhere in the
> implementation specifics: cookies, etc.
I agree this is much easier to read & more flexible.
> The method of substituting alternative screens, as you have,
> is Transfer. The other way is Redirect, which causes a trip
> to the client, but will provide a different URL--whether it's
> good thing depends on intention--whether you want to show the
> difference between public and secure parts of the web site.
Yes, I tried redirection successfully, but I think I prefer transfer for
this usage.
> 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.
> 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.
How would mimeForFile determine the mime type of a file? Or would that
just be a lookup?
> > '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?
> > 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?
> Unconditional hrun is 0!:[EMAIL PROTECTED]
Thanks, that's nicer.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
