First impression of Xojo WE

I had my web guy, who codes in php/javascript/html/css and who is just learning Xojo, recreate a page that he recently created in javascript in Xojo WE, just to get his first impressions. I fully expected a litany of why “pure” code was better and how clunky Xojo was in comparison to the elegance of what he was used to. I was surprised to hear him say, “That was a lot easier to do in Xojo. I didn’t have to do all that fiddling around to make it look the way I wanted. It only took me an hour to do what would have taken half a day.”

Nice job, Xojo! Funny how “elegance” so quickly gives way to pragmatism. :slight_smile:

It’s indeed a lot faster to conceive some works, but a lot heavier to execute some produced content too (due to it’s single thread (one core) and server side event handling only nature, and CPU intensive consumption with multiple parallel clients. So, it’s a trade off, choose carefully. Some people just don’t accept the speed of some controls feedback and lack of simple client side event processing they are used to (like click a checkbox and wait…the…round-trip…server…event…processing… and it’s ticked and a label changes. :wink:
For intranet uses with a small number of parallel users, it’s usually fine; for internet if you have some payload, you probably will have to create a good virtual infra to use it and have some headaches to maintain it.
I felt it was necessary to say this because some people could expect it being the solution for many problems, and it’s not. So, understand your tool beforehand (as Tim is doing) or you can finish wasting hundred of hours in something and needing to redesign it later using other tools. :stuck_out_tongue:

I just completed a small web site I needed as companion to my first iOS app. It needs to manage rotating devices, a toolbar, and offer a web form for email. Nothing fancy. I experimented with Xojo but it is a lot less flexible than HTML+css+JavaScript pages, and getting a nice visibility in Google is a hassle. So now the site is mainly HTML+css+JavaScript, and only the mail form is in Xojo.

It is quite true that it took me more time, though. Maybe because I was getting rusty in HTML ?

I am still convinced Xojo Web Edition is a fantastic tool for web applications, far faster and easier to use than HTML+css+JavaScript, and close to impossible to equal in php. The issue is scalability. HTML pages take very little resources to serve, so they can take a huge amount of traffic, where Web Edition will eventually choke on too many visitors.

Mixing the two gracefully is probably the way. At least for me :slight_smile:

That’s the approach we’re taking on a current consulting project. Probably 75% WordPress site and the rest in Xojo.

[quote=157397:@Rick Araujo]
I felt it was necessary to say this because some people could expect it being the solution for many problems, and it’s not. [/quote]
Sounds a lot like the requirement for designing any system - know your users, know your use cases, know your data BEFORE you decide what technology to use.
Then choose & design appropriately.

The Google part is easier with 2014r3 as we added the ability for your app to respond to requests from search engines.

I am not sure I see what you mean. GoogleBot is still an unsupported browser, so it cannot access the content of the pages to index them anyway.

Some members have succeeded embedding google tags to obtain visit statistics about their apps, but still, the content cannot be indexed.

The addition of HandleURL may allow pointing GoogleBot to virtual subfolders with a sitemap.xml, but it will still requires preparing and serving specific textual content for GoogleBot to index, and this leaves a thorny issue of dealing with visitors coming from Google directly on that URL and what to do with them.

Or have I missed something entirely different ?

Bob, that may make an interesting training video.

[quote=157444:@Michel Bujardet]I am not sure I see what you mean. GoogleBot is still an unsupported browser, so it cannot access the content of the pages to index them anyway.

Some members have succeeded embedding google tags to obtain visit statistics about their apps, but still, the content cannot be indexed.

The addition of HandleURL may allow pointing GoogleBot to virtual subfolders with a sitemap.xml, but it will still requires preparing and serving specific textual content for GoogleBot to index, and this leaves a thorny issue of dealing with visitors coming from Google directly on that URL and what to do with them.

Or have I missed something entirely different ?[/quote]
No, you have it right. You still have to provide textual content. There’s no getting around that but at least now you can respond.

One of issues I find is that : Google indexes separate pages. So in order to feed the robot content to index, the best way is to provide a sitemap.xml file that contains all the virtual paths to pages, which will enable sending the proper text content.

Let us say Google indexes a page myapp.cgi/gadgets/ that contains the word widget. Now a user looks for widgets in Google, and gets a link to my app. When he clicks, he will be lead to handleURL. If I do nothing, all he will get is a crude text page destined to GoogleBot. Yuk.

Now if it is a supported browser, I want to take the user to the corresponding page within my app. Since ShowURL does not work within the app events, I need to use a meta refresh to send my user to the app, with a parameter, for instance http://mydomain.com/cgi-bin/myapp.cgi?page=3

Problem is, so far I found no way to get the user-agent header, so I have no way to know if it is Google or a normal browser.

Unless I missed something, we got only half part of the solution : search engine crawling is possible with a heavy additional dose of coding, but so far I see no way to separate bots and normal users, so effectively showing these nice visitors coming from Google my app is not possible. We still need that extra inch, and it will be complete.

Not if you look at the user-agent. If it’s an actual browser, send the user to your app.

If it’s a supported browser, just return False and the framework will take over.

dim h as string = request.getrequestheader("user-agent")

You do need to generate data that Google can handle. The search bots typically don’t run javascript and that’s the only way that our framework actually gets data to the browser. You’d need to generate the data in a generic way that Google will accept, and that’s not something we can do automatically for you.

I was looking at request.header("User-agent"). OK. That was the extra inch needed. Thank you.

Once the proper tags are sent, as well as keywords and description of the page (Google has an excellent guide to search engine optimization), all it needs is pure text, which can be sent in one load in between and . That should suffice to ensure a decent indexing.

One of the nice things about that technique is that the text fed to Google can be more elaborate than what the app pages show. Actually, the more verbose and literary the text offered to the bot, the better the ranking. And the app page can be more sober :wink: