Hi,
I am having some troubles with the scriptcase variable…
If in an application I have a select with the parameter [ID_TEST] and this parameter is passed by a GET, why it is always a session/global variable? If I open the same generated application in two different tab in the browser, the parameter passed to one tab is received also from the application in the other tab…
I try to put sc_reset_global in the first event, but in this way the parameter is not read… I put it in the footer event, but here it have no result… I want simply that a parameter passed with: ?ID_TEST=5 have only the target applicatio as scope… I must use the $__GET? there isn’t a clean way under scriptcase?
I hope that my description of the problem is almost clear…
Thank You in advance…
I’m not sure if this is the answer, but global variables are not session variables. You don’t access global variables by the url, say $_GET. In that case you could have an onapplicationinit even where you can set [myglobalvar]=$_GET(‘myvar’); Regarding tabs, it depends if you have blocks working as tab or applications within a tab application. In that case each application runs in his own IFrame and you will find in the faq how to pass variables between them. This might be of help too: http://scriptcase.aducom.com/cms/e107_plugins/faq/faq.php?0.cat.6.6
When I speak of tabs I intend explore/firefox/chrome tabs… I see that if I pass parameters via GET and then access ot via [ID_TEST] in a browser tab the same value is taken from the same app open in one other tab… It’s not easy to explain… For example I call the app from a blank with myapp/?ID_TEST=value, how I can make a select with where id=value without make id_test a global variable?
This is absolutely a false statement.
Prove it yourself. Create a Blank app with the following code:
[test_variable] = "ABCDEF";
echo "<pre>";
var_dump($_SESSION);
echo "</pre>";
and you will see the session variable ‘test_variable’, accessible through code as $_SESSION[‘test_variable’].
A Session is simply a group of variables (in our case, php global variables) on a particular server used to store application state information.
When a browser requests information from a server that is running php, it uses a cookie (usually called PHPSESSID) to tell the server’s php which session to use. Cookies are referenced not only by their name, but also by which URL they are attached to. For instance, “http://www.google.com” and “http://www.yahoo.com” can each have a different PHPSESSID cookie, so each has a different session number to use when they communicate with their respective servers.
All tabs in a browser that reference the same server URL share the same cookies. As a consequence of this, all tabs that reference the same server URL share the same session. That is how browsers work. It has nothing to do with scriptcase. It has been that way since tabs first appeared in browsers.
Hacks around the problem:
Most browsers have a way to open a window that has a separate session - in Firefox it is called a “Private Window”, in Chrome it is called an “Incognito Window”, etc. These windows do not share cookies with each other, consequently the server treats the requests as though they are coming from different PCs: each has a different session.
You can have multiple URLs for the same server. If you configure multiple aliases for an HTTP server, like “test1.mydomain.com” and “test2.mydomain.com” then they will have different PHPSESSID cookies and so they will have different sessions, if they are each open in a different tab in the same browser, even though it is actually the same server serving the same pages.
Instead of having the server retrieve a cookie to get the session ID from the browser, the session ID can be passed in the URL. Scriptcase will supposedly support passing session IDs in the URL if you enable this option. Although very powerful, this approach is fraught with perils and requires in-depth knowledge of browser/server interaction and a well planned and executed design.
Another side effect of the way sessions work:
Besides the obvious problem of multiple tabs sharing the same session, another problem of current browser/session design occurs if you have multiple servers in a cluster in order to support load balancing or high availability. Server A and Server B would be keeping a different set of session variables for a particular browser. If you get connected to Server A on your first page request, and then Server B on your next request, the variables would all change. This problem is generally solved by enabling the storing of sessions in a database that both servers share. When the page request comes in, the server gets the session variables from the common database instead of its own session file. Scriptcase supposedly supports storing sessions in database.
More information on sessions can be found here.
Dave
Ok… I know how session work, what I can’t understand is how to avoid that if I pass a parameter in scriptcase by GET it becomes a session/global var… i don’t understand why scripcase uses so massively global/session vars that instead must be used with attention… You can’t never know what the user do with an internet page, and with all the iframe that scripcase use (this is another big problem) there are a lot of unexpected results…
Perhaps the indication of session/get/post in the global variables setting is absolutely no use… If I deselect session var and I leave only GET the session variable is evry time created…
From what I have seen, if you use square brackets to reference a variable anywhere in your code, it becomes a session variable. I do not think that the options in the global variables settings do anything (except for In/Out).
I agree with you. Because of the way that each “app” is treated, it forces the programmer into using many more global (session) variables, or hassling with lots of hoops to launch another “app”. Somebody at scriptcase really needs to totally rework the sc_redir paradigm.
Sorry for the lengthy discussion about sessions, but many people ask all the time about browser tab variable interactions. Now I can give them a link for this topic. 
Dave
[QUOTE=daveprue;31714]From what I have seen, if you use square brackets to reference a variable anywhere in your code, it becomes a session variable. I do not think that the options in the global variables settings do anything (except for In/Out).
I agree with you. Because of the way that each “app” is treated, it forces the programmer into using many more global (session) variables, or hassling with lots of hoops to launch another “app”. Somebody at scriptcase really needs to totally rework the sc_redir paradigm.
Sorry for the lengthy discussion about sessions, but many people ask all the time about browser tab variable interactions. Now I can give them a link for this topic.
Dave[/QUOTE]
Tnx Dave. The session option with the global variables has always been a question for me. However, loads of times I cannot get access to the vars using $_SESSION and I need to use $_GET. I know that if you pass parameters with sc_redir you will create new global variables in the called application. The inconsistancy is that if you want to pass a global variable by sc_redir you must not use the brackets. Other problem is that if you set a global variable and do a sc_redir without these parameters these are not becoming available. Useually you need to refresh to see the latest status of the global variable. That’s why I always pass the needed globals using sc_redir and don’t trust the $_Session. But it’s very well possible that it’s not the best way, you learn to work a certain way ‘because it worked the previous time’. I agree about the sc_redir issue.
Albert,
You point is well taken.
I would have to conclude that if some of the most experienced users of scriptcase do not fully understand the handling of variables, this points to the fact that the documentation and/or design is lacking and ought to be addressed by NetMake.
Dave
[QUOTE=daveprue;31719]Albert,
You point is well taken.
I would have to conclude that if some of the most experienced users of scriptcase do not fully understand the handling of variables, this points to the fact that the documentation and/or design is lacking and ought to be addressed by NetMake.
Dave[/QUOTE]
I have not the pretension to know it all and I doubt that I’m one of the most experienced users, just because I’m active on this forum. Giu, JSB and others have been great answering questions here too. I have the intention to help people out within the knowledge I have and sometimes I make mistakes. We all learn from each other. That’s the basic idea.
So I should conclude that I must use $_GET to get the parameter? and I should never refers to [ID_TEST] otherwise a global var is created? I must admit that this behavior is very strange, I prefere that all the avrs have as scope only the app and that I must esplicitally declare if a variable is global…
Perhaps I have noticed another strange variable behavior during my tests: if I have [ID_TEST] as parameter, $ID_TEST exist and contains the same value… oh my god… all this are garbage data… useless redoundance… no one think to memory waste and to security? I must put on scriptcase some sensitive data and I must double check always the security… This will complicate a lot my work…
I found this article that confirm my thinks:
http://www.scriptcase.net/knowledge/index.php?/Knowledgebase/Article/View/334/40/variable-sending-by-url
we should use only get and never [var], if not absolutelly necessaire… We can’t have a sc_function to get this value? if Scriptcase is a software for “non programmers”, I don’t want to teach to non-programmers how to do it… also because get a value from $_GET include a lot of other control/validation for security reason…
[QUOTE=insecta;31728]So I should conclude that I must use $_GET to get the parameter? and I should never refers to [ID_TEST] otherwise a global var is created? I must admit that this behavior is very strange, I prefere that all the avrs have as scope only the app and that I must esplicitally declare if a variable is global…
Perhaps I have noticed another strange variable behavior during my tests: if I have [ID_TEST] as parameter, $ID_TEST exist and contains the same value… oh my god… all this are garbage data… useless redoundance… no one think to memory waste and to security? I must put on scriptcase some sensitive data and I must double check always the security… This will complicate a lot my work…[/QUOTE]
Can you explain what security problems you see?
The fact that the data is in the url and thus visible. But you can also post data and use $_POST. The mentioned article is not realy relevant imho as this is only one of the ways to pass data. In fact if you redirect to other applications while using global variables then you will see that these are not passed in the url. [ID_TEST] means that $id_test is created. Yes of course, that’s because [var] is not valid php and is only used to generate valid php. If you need local variable only to be used in your current app then you can simply use the $var notation. In your case you can also create a custom field and use the {} notation. Then you don’t have a global variable then. But you need to assign the passed variable to it and if you pass it in the url you get someting like {myfield}=$_GET(‘myvar’);
The fact that the data is in the url and thus visible. But you can also post data and use $_POST. The mentioned article is not realy relevant imho as this is only one of the ways to pass data. In fact if you redirect to other applications while using global variables then you will see that these are not passed in the url.
Exactly. This is what I means. Data is passed in URL just when you force to pass as variable.
I did some tests on a blank app, with this code.
$getvar = [prueba];
echo $getvar;
Prueba is defined as GET global var.
SC asks for this var on execution as with every global from dev but ignore the value passed, just if I call blank app like /bln_testvars/?prueba=fromGet echo prints fromGet. Internally SC saves this var as a session var, but ignore it. SC just update this var in SC session if you pass this variable in URL. Obviously, this way, you have to control with isset() if $_GET is passed and die() if not, as in any PHP.
If global is session, it works as expected. It don’t check URL to update or not, and always update session var.
As suggestion to NetMake, they should take note on this, and if a global var is defined just as GET, then they must sure in session is cleared, or directly not use session (better approach)
SC is over 10 years old and it needs freshing up here and there. I guess they don’t want the risk of breaking code. Not in their own code, nor in the generated code. But your explanation makes sence. In certain situations you will see that changing a global variable does not update the data in the source application and that you need to refresh. I use the sc_redir with the passed variables then. I found that strange, but over time you get use to it and you simply do it that way and don’t think about it again. David has a point there.
With the global variable construct, any code can use the data stored in the variable any way it wants regardless of scope or reason. Access rules can be broken and the data can be invalidated by a reckless write. Unverified access means untrustworthy data. If I’m working on a business intelligence app this can be a problem because I need that all the data are “sure”…
I know that updating the code will sure origin a not-consistence in app, but I think that in 2015 some behavior are unacceptable… the massive use of iframe, the massive use of global vars, the lack of HTML5/CSS3 and responsivity in template… Also the not “open source” policy is a problem for me… In Italian Public Administrations we are abandoning the actual infrastructure because is not open-source… but in our structure there are a lot of not-programmers coming from oracle forms… needing to migrate them in the “new age”, scriptcase is a good way… It generate php and work on apache (also if we still use oracle db in our projects), but if I want to correct a bug or extend something there are a lot of limit (the lack of third party plugin is also a limit thet, if removed, can surely expand the possible users of scriptcase)
Saying this I don’t want criticize scriptcase, the product, with his limits, have a lot of good points… but it need just an “improvement”… because it is sure valid but it can become better…
Yes, I recognize the open source discussion, we have that here too. But that said, I have loads of samples which causes open source project to be overpriced compared to commercial apps. If you use open source, you need to have the intention to put some time into it to improve, and most users of these apps are just consuming. On problems they simply have to wait for fixed out of the community, there’s no company who can be addressed.
I don’t mind that SC is closed source, but I would welcome if the templates used for generating code would be more open so that the community would be able to fix issues. We have found issues from the generated code, applied fixes to SC and found that they did not use the code but solved it a different (and in our case bad) way. They have a small team,any help would be helpful IMHO.
But you cannot completely redesign an application over 10 years old. Responsive design, css3, html5, are all new developments and it will take time to integrate that into SC. I know that they are working on that, but if you don’t want to break code you have a problem. You don’t have happy users if you break the code and users must fully redo their application.
Regarding security, I see it different than you. Any code can use… well you are the designer and you are responsable for the code on the server. It’s only a problem when things get hacked, but then again you have other issues at hand. If needed you can put the code through NuSpheres or Zends obfuscator the code will even run faster too. I don’t see the danger of having IFrames, lots of globals etc. But that doesn’t mean that I wouldn’t love to see divs in stead of iframes and another way of dealing globals.
If You work in a structur with 100 developer, with a lot of external source, this IS a big problem…
If You must respect accessibility in Your apps, iframes ARE a big problem…
But SriptCase is not a tool for a structure of 100 devs. A structure of 100 devs doesn’t needs a RAD, and any RAD fits on this structure.
If You must respect accessibility in Your apps, iframes ARE a big problem…
You are right here. Maybe on V9, who knows.