🚀 go-pugleaf

Dear Remigiusz,

Are you from Poland, aren't you ?  Glad to talk with someone from there :)
See my answers between the following points you put:

Remigiusz Sokolowski wrote:
> 
> > 3) The form stack & client's back-button limitations I bypassed stopping use the pageno
> > and multi-form schemes. In reality all this application that have almost 700Kb of code and
> > more than 30 different "pages" use only the pageno=1. I have multi-form archives (JFM) but
> > only one (the entry one) is accessed by the client and the others are just classes
> > definitions that the former load when necessary. With this orientation there is only one
> > "f.open()" - example :) - when the app is started by a session and only one "f.close()"
> > when (and if) the user clicks the "end session" button that I put in the Home Page (as the
> > banks do). In no part of the application there is a _sys.scripts.run.
> 
> Here my question:
> I thought, that form stack is created evary time - just because You open
> new form - am I wrong?
> 

You're right. Yes, it's created indeed, but what I am doing is not been attained
to the complications that this stack imposes to us designers, only not giving to
it any other form to be put in its (stack) top. The application has only one
opened form, let's call it "Starting.jfo" (I never use the JFMs! - but it's not
relevant now). When the user asks the Starting.jfo (first entry) it's runned by
IB server and then for this session is created a new brand form's stack. The top
form in the stack is Starting.jfo. Inside this form I load (once only) each
additional form I need (and just when it's first need), for example "login.jfo",
but not calling _sys.scripts.run("login.jfo") which will put it in the stack
top. I first load it with _sys.scripts.load("login.jfo") and then I instantiate
a new object of the class that is inside the "login.jfo". From this point now I
can use whatever is inside the login class without concern about who is in the
stack top. Always the "Starting.jfo" is in the top. I could "paginate" to the
login "screen" only changing the pageno property and letting IB send it back to
the user's browser.


> > 5) With the benefits of doing the iten 3 above, I could use as many frames as I did need.
> > There are also pop-up windows, automatically opened and closed windows, etc. And all of
> > them are updated with data came from IB and all of them can post data back, with no one
> > conflicting or been missed in the process. Can you imagine 3 frames plus 2 pop-up windows
> > operating in the same time from one IB application ? It works.
> 
> Here next question:
> What about security - or may be You doesn't use it?
> In my applications I use security objects from built-in solutions of
> Borland - it is very hard use it in frames because of authentication
> should be made only once and here it will be for every frame.
> Have You any of such features in Your app?
> 

I don't guess what kind of security are you talking about. I don't use database
security. But this application has two security levels. First it's divided in
two access areas, a Public one where people can browse a products catalog and
ask to be registered, and the other area is a Restricted one. To gain access in
the restricted area the user has to pass through the login "screen" where he has
to inform his company's pin number, his personal login-name and his password.
>From that point on the application knows who is accessing it (because for each
user request is opened a new session in the IB server and IB controls whose
session pertains to who). The second security level is that for each user can be
assigned an "access level", so there are users that can only send orders while
other users can edit data files, etc... I really don't know what is "security
objects". I never did need them. We're using other protection layer in the
access that is a https protocol.

> I find that there is some possibility to provide security from application
> using frames by using second hidden field - there is stored session id -
> it can be passed to next forms and this way it is recognizeable where is
> client. 

This point is in the core of the subject I'm exposing to you (all). I don't need
to care about passing stuff to other forms, just because I'm processing every
form inside the entry one. All state variables and data I need are there
everytime for every "form" (class) to access. So, in every moment any of the
application's modules (there are about 20 of them - different JFOs) can know
everything that happened before (and that I feel worth of keeping safe in
memory). Everyone (classes) can talk each other and I never have to concern who
is in the stack's top and neither I need to pass it as parameters to others
forms. So, Remigiusz, I believe I am doing the security you talked about, but no
frame need to know that and then there is no difficulties. The application knows
who is accessing it and know also that user's access level, so if he asks for a
non-authorized option, let's say the "Edit Company's File" option, the
application sends to him a "Sorry, you can't!" screen - and he continues from
there to other authorized options. I'll tell a secret... I have a frame where is
the site's menu that it's not even a IB form, but I edited the HTML of this page
adding something usual from IB forms, that it fools IB thinking that it's one of
his form and he replies the requests happy :)

This is the shinning point in using IB other than InterDev. The session is
there, active, with all the running situation of that user available to the
application. 

** Please, Inprise, don't kill this so powerful tool. You can put in the fame's
podium only doing some adjustments. Let's make M$ eat dirty. **


>But I don't know if there is a posssibility to use objects from
>this session in others sessions by refferencing to them
> 

Ok. If you change the way your forms are calling each other (or even the links
that go to the browser) and they always SUBMIT the form back to IB (from any
frame that it is) you can integrate your application in a way that there'll be
only one session for each user access. In doing that there's no reason in "using
objects from
other sessions", that is a real impossibility; or are you planning to let the
users talk to each other through IB server ?


Regards,
MMM
-- 
       ---------------------------------------------------------
       "Who is General Failure, and why is he reading my drive?"