Quantcast
Channel: West Wind Message Board Messages
Viewing all articles
Browse latest Browse all 10393

Re: No Are Parameters Passing

$
0
0
Re: No Are Parameters Passing
FoxInCloud
Re: No Are Parameters Passing
05/14/2012
04:43:58 AM
3I30A582M Show this entire thread in new window
Gratar Image based on email address
From:
Thierry Nivelet (FoxInCloud)
To:
Attachments:
None
Dynamically opening tables should not raise any issue - they will remain USEd through the life of the form.

User-dependent tables should be (re)USEd in:
- form working in global datasession: xxxProcess::wUserSet(wUser)
- form working in a private datasession: xxxFrm::wUserSet(wUser)
where wUser is your application's User ID key
There is another detailed thread on that issue


Hello Thierry,

Have basic std_tab methods up and running. For now I just create new forms and that seems to work.

How would you go about dynamic opening from tables ect. At the moment I have to code manually all tables in the load of the form to open
In my LAN setup all of this is done dynamic.

I call somewhere form.mgr_data.select("groups) and it will everything for me i.e open the right table from the right customer or select it if its already open. How would you deal with that in stateless environment ?

Theo


Hello Theo,

Thanks for these detailed explanations

In LAN context, each user 'owns' an instance of a form; this instance can be highly customized with dynamic addObject()

In Web context, all users share the same instance of a single, shared form.
FAS saves / restore the state of the form and dataSession after/before each request.

So far FAS does not support saving / restoring user-dependent custom objects
Objects may be customized through Form.Init(), as far as they are created/added to the form before hand.

What we might be able to do is a new syntax where you can specify an alias for each variation of the same class / form

xxxProcess.wFormStandardPage('Form AS Form1', <other parameters>)


Hello Thierry,

I will do so, I can get a lot to work but some issue need either a different approach or recoding in the base application wich is not always bad.

Fore instance, took you wwait example and ported the whole application thru a similar process i.e. created a mgr_wait class where all wat window stuff goes thru. This resulted in that faa only needed to adapt one statement. OOP and OOP again. Most stuff is pretty OOP based so i am running into some issues with that.

We use a lot of factory stuff

For instance: I have the base class std_tab

This class gets fed in some parameters and sets up a tabular grid for the table passed ect ect.
All our basetables i.e products. departments,groups ect ect are all shown on opening in a tabular manor
We use free tables and only open them JIT i.e. just in time

Setting up works but it seems that FAA relies on the actuall newly created object to exist as a class when doing row changes ect ect
I can understand that from a stateless point of view but it would mean creating a lot of new classes based on the baseclass.

Any ideas

examples

object = thisform.wform("std_tab",.f.,"groups_prc") -> creates a new object with the name groups_tab
gets shown on browser ect ect but when doing rowchanges it complains about object group_tab not being available

Due to the stateless situation faa wants to run the code thru groups_tab but for some reason does not seem to find it

Any ideas if all of this makes sense.

Theo


Could be nice to post back when you find a workaround and/or a valuable suggestion.
my $.02


Hello Thierry,
Should have come back earlier,
Managed to solve this issue by a matter of deduction ;-)






Viewing all articles
Browse latest Browse all 10393

Trending Articles