Hello DerkJ.
The Invoke method would not work, because inside the “Constructor” you would have to use XojoScript which does not have the ability to handle objects like WebPage.
Thanks for the suggestion.
Hello DerkJ.
The Invoke method would not work, because inside the “Constructor” you would have to use XojoScript which does not have the ability to handle objects like WebPage.
Thanks for the suggestion.
Dear Tim Hare,
It is not true that XojoScript is designed to be a highly isolated environment, if it were as you say it would not have the “Context” property, its function is to connect with the properties and methods of the object taken as context.
Maybe you have more information about what’s going on in the heads of Xojo engineers. At least I ignore it; telepathy is not part of my hardware.
I have suggested, in a comment above, that WebApplication should have the “Pages” method similar to the “Pages” of the “Session” class. That is, “Session.Pages” contains the instantiated WebPages, my suggestion is that “WebApplication.Pages” should exist with all the WebPages that the application contains, instantiated or not.
Maybe, you can talk to Xojo engineers and tell them my suggestion.
I don’t understand why you need to get an array of the pages that you can instantiate dynamic. You project is build and there you can automate things. The pages say “homepage” etc are all permanent for each build so you can create an array using build automation or such or ide scripting to embed in your project.
There is no way to “design” pages in a build application other than to have a page be setup to be dynamicly constructed. But then there is the possibility to add a string property to the page to pre define what it’s purpose or name is, the other stuff will be dynamicly generated like labes, textfields etc. Even trough your xojo script.
Not as an object but it can be done.
I don’t think xojo would develop such just because only you need it… but a feature request could clear things up?
Sorry, DerkJ, you don’t see the scope of the implementation of the “Pages” method in WebApplication.
APPEALING TO YOUR IMAGINATION.
Imagine that you have the list of WebPages of your application in a database table. With that table you can create views according to the pages that a given user has been given access to. Then, the options menu becomes dynamic because it is built based on the view.
In the program you would not need to be maintaining a method every time you add or delete a WebPage using a long SELECT CASE statement, you would only need to retrieve the name of the WebPage from the database table, look for it in “WebApplication.Pages” and execute its “Show” method, the same way you would with “WebSession.Pages”. The difference is that in WebSession only those are instantiated, while in WebApplication they would all be instantiated or not.
So, the implementation of “Pages” in WebApplicacion would be extremely useful.
Uhmmm. Maybe I’m asking too much of your imagination.
Please refer to the tagline of this forum: friendly help for the Xojo community. Everybody has been helpful and respectful in trying to assist you.
Looks like your intelligence and competence are above that of anybody else in this community. Why don’t you write a new development software that will implement all you can imagine, and then sell it to us ?
Dear Eric Williams,
Some people who have tried to contribute solutions have been kind, others not so much. However, I am not complaining about the displays of contempt shown towards me. Come on, I’m an adult, not a whiny child who cries in every corner; Keep in mind that I am talking about myself when I say whiny child. It’s not going to be that because I address these adjectives to myself that someone feels offended.
Can anyone say I haven’t been kind?
I have always appreciated the time they take to give me solutions, and I have been deferential to each of them.
Maybe this part of the community doesn’t like me criticizing a development tool like XojoWeb. Additionally, I’ve contributed the idea that Xojo engineers, if anything, are okay with adding the “WebApplicaion.Pages” method. Obviously I don’t think they take this contribution into account, it’s more than likely that they don’t even know I exist, I must look like a tiny drop of sweat on a fly.
So, friend Eric Williams, I will appreciate you being direct and telling me with crystal clarity what the offense is, I have already told you, I am an adult to take things in their proper dimension.
My very dear friend Gilles Plante.
I gladly read your insulting comments, it seems that you have put a lot of salt and pepper and shaken it quite vigorously. And then he says, between the lines, your best friend Eric Williams, that I’m the disrespectful one. Maybe it’s time you followed Eric’s advice: “Please refer to the tagline of this forum: friendly help for the Xojo community.”
Someday, when I have the necessary resources, I will create development software… But, I wouldn’t sell it, I would give it to you for your own benefit.
I don’t know if my intelligence and competence are above others, I think I’m average, probably on the threshold of the previous level. But, of one thing I am completely sure: as an analyst-programmer I know what I want.
Actually, it is. You can do a lot by expanding the context, but at that point, you might as well be writing native Xojo code. One of the peculiarities of Xojo is the fact that you can’t create objects based solely on a string representation of the object name. That’s not how the language works. XojoScript is not a way of circumventing that limitation (if you want to think of it as one). You would be more successful with introspection.
What would you envision an Application.Pages method to return? And wouldn’t that require creating an instance of all the pages? Or would it return an array of page names, which puts us back to Select Case being the best solution.
Since i’ve read it all but it’s not a 100 clear in how you want to achieve your goal. And having said that, xojo is a tool like a hammer it does what it provides to you. Not the other way around, so please make a feature request for any you may have or be a little less provocative.
Edit, we are all happy to help if we can.
Maybe you can try the vanhoek plugin that can handle objects from xojo to xojoscript is i read.
@Enrique_Orellana_gutiérrez
http://vanhoekplugins.com/REALStudio/Scripts_Plugin.html
FWIW, you can do Xojo objects in XojoScript, it’s just a lot of work.
XojoScript does support classes and Modules, but you have to write the code for them. Things like
Class Timer
...
End Class
And you have to rebuild the structure for everything you need.
But then XojoScript can only pass intrinsic types to/from the parent app (through the walls of the sandbox) so you also need to create infrastructure to create, manipulate and store instances in your context. It’s not horrible to do, just time consuming. I did it with the Regex class as part of the IDEs implementation of code editor scripts.
That said, this still doesn’t get you what you are asking for. There’s no way in the general web framework to instantiate a web page from a string. You can’t simply say
Dim X as new WebPage("my page")
And that’s partially because Xojo apps are compiled binaries. Things that you don’t use in your project are not actually included in the final binary.
Introspection doesn’t get you there because it works on already created instances.
NOTE, this question has been asked over the years about Xojo itself (not just web) and the answer is usually the same. That the user is expecting Xojo to behave like whatever compile-on-demand scripting language they’ve used before. The fact of the matter is that Xojo work this way…and it’s not a bug that it doesn’t.
Hi Greg O.
I am glad to be able to share my ideas with you and thank you for spending a little of your time with me.
I confess that I do not have the knowledge to develop a programming language, although I read somewhere on the Web that there are resources for any programmer to develop a computer language, obviously not on the scale of Python or Java.
For example, in VFP the DO command is used to execute a program or procedure. If I have a form named “myWindow” I would execute it like this:
Do myWindow
A form in VFP is Window in XojoDesktop. The same command in VFP, in XojoDesktop would be like this:
myWindow.Show
And in XojoWeb, myWindow can be the name of a WebPage:
myWindow.Show
But, in VFP I can also do this:
lcFormName = “MyWindow”
Do (lcFormName)
Or
Do (“MyWindow”)
Like I said, I don’t have the knowledge to build a Xojo, but there are logical issues in any software.
Why does the MyWebPage.Show statement instantiate my page? Or in other words, what happens with MyWebPage.Show?
MyWebPage must be compiled and part of my application. Even my page name needs to be on some stack for the iteration. When I apply the “Show” method, some routine looks for the MyWebPage reference and another routine instantiates the page. That is, all the webpages that I programmed are within the final application. If my logic doesn’t fail me, there could be a “Pages” method similar to “Session.Pages” that can have the complete collection of all “WebPage” references of my final application. Then, you could use the following statement:
For Each oPage As WebPage In Application.Pages
If oPage.Name.Lowercase = “mywebpage” Then
oPage.Show
End
Next
Better yet, if it were similar to a Dictionary class, it could be like this:
Application.Pages(“MyWebPage”).Show
As a programmer, this resource would be very useful.
Good, DerkJ.
I have taken note of this plugin, I have even downloaded the demo. Although due to its age (April 3, 2019) it may not work in the current version.
Anyway, thank you very much for the suggestion.
If it is used nowhere, it doesn’t have to be part of your binary.
You can not do anything with a Webpage on Application-level.
Webpages need a Session. No Webpage without a Session.
You can get waht you want with
WebSession.PageWithName(pageName As String, implicitOnly As Boolean) As WebPage
I which case would an array of WebPages at Application Level be useful?
Then don’t post like one.
In my case (not a web app), some are in string properties, simply because they are small. One or two others you will find in the app’s Resources Folder, which is also where all the images are to be found, along with one or two other items. None of the items which are not string properties are in the executable.
You might consider keeping all your webpages in an SQLite database. You can read in their names and populate a listbox with the names, and add the ID of the page as RowTag for the row. Then when the user double-clicks on one you read out the page content from the database. No XojoScript there at all.
Now, the above is what I would do (and in fact DO do) for a desktop app; I don’t do XojoWeb so have no idea how that would translate to a web app.
Frankly, I think he should consider keeping all of his development in another tool. He’s obviously dissatisfied with the way Xojo does things, is not interested in explanations why it is this way, or advice on approaches that will work within Xojo.
Like he constantly reminds us, there are many (many, many!) web dev environments. He’s right! And I’m sure one of them would be better suited to his extensive skill set and exacting requirements. So - as far as this particular thread is concerned, perhaps we should simply let him find his own way, even if that means him leaving the Xojo community. I suspect everybody involved will be happier.
That is known as Implicit Instantiation. It is a shortcut for beginners and is generally advised that you grow out of it. There is a setting on the window that you can turn off.
In Xojo, windows do not have names. Consider the following
var w1 as New Window1
var w2 as New Window1
var w3 as New Window1
Which of them is “Window1”? None of them and all of them. When you create a window in Xojo, it is essentially a class, not an entity. Implicit Instance allows you to treat it like an entity in code, but it really isn’t. Xojo may create a property named Window1 on your behalf if you leave the Implicit Instance property checked, but it’s not required. And is actually discouraged.
If you leave Implicit Instance set, Xojo writes a lot of code behind the scenes that creates the page and displays it. There’s a lot going on there. If you turn off Implicit Instance, you have a lot more control over the creation of the window. A common error for beginners is to have a reference to Window1 in their code which unexpectedly causes the window to be created and displayed (if Visible is also checked, which is the default).
There are many languages that allow this. Xojo is simply not one. You are welcome to submit a feature request through the issues site. It may be a reasonable request, but you’re fighting 30+ years of precedent.
Therein lies the problem. If it’s not used, the compiler will strip it out of the app entirely. It simply won’t exist.
Also, note that the Session.Pages method returns only the currently instantiated pages, not a list of all potential pages.
And I think this bears repeating: windows do not have names. Xojo allows you to treat them as if they did have a name, but not really. A window is a class, a potential entity. You can create one or more of them, but they are not identified by the name of the class. You can use the IsA operator to determine the class type of a given window, but you cannot (aside from Implicit Instance) address them by name.
Dear TimStreater,
I read with great satisfaction someone who understands what automation is. What you do with SQLite I do in MySQL. In fact I have tables of users, user permissions, the reference of all the WebPages of the application, that way I have better control of the main menu.
I even configure some application processes in tables, this way I don’t have to reprogram, compile and install, just create keys in the corresponding table for adjustments according to the client’s requirements.
I have been using this solution, the use of tables for references to forms in VFP (a form is similar to Windows in XojoDesktop) for more than 20 years. It seems like an efficient solution to me.
The only stumbling block in “XojoWeb” is that you cannot execute, by substitution, the instantiation of a WebPage, there is no such thing as [oPage("mywebpage").Show
] so I am forced to write a long list of Select …Case, and every time a WebPage is added or deleted you have to update the Select…Case. It’s a can!
Truly thank you, TimStreater, you have been an oasis in the desert.
An affectionate hug.
I feel you man. On desktop, I haven’t found anything better. I must confess that in 30 years of using Xojo, I’ve gotten used to its excentricities. And I have parameterized the heck out of my desktop apps. It works really well. At the same time, I abandoned XojoWeb in favor of other solutions. There are many that are better in that workspace. You have to make your own determination of whether Xojo is right for you. No one’s going to look down on you for whatever you decides works best.