This is the second part of my HOW-TO. It refers to the first part and describes, how a USP works.
PART 02: Getting Uniface involved
Calling Uniface is an easy one. Basically we just put the address of the server page into the browser and wait for a response. At this point I don’t know how the server pages were meant to be (ab)used but when you are out there and do the web development, then your code is capable of doing more than ONE THING at the same time.
As you might know, we can activate component operations in order to reuse the given code. Actually this also works within the USP 🙂
Let’s say we have the server page “myusp”. Calling it in the browser makes us see some html (or whatever it should show). Now we append another operation called “hello_browser”. Using a normal activate would make it look like:
… right? But we don’t activate while using a browser. So to get that operation to run, we amend the address of the server page to “myusp.hello_browser”. Try to make an operation with the following code:
$webinfo(“OUTPUT”) = “<html><head><title>Hello browser</title></head><body>This is the operation HELLO_BROWSER serving you!</body></html>”
Now take a look at the SetState trigger. If there is a WEBGEN then just remove or move it to the execute trigger.
Press [CTRL]+[F7] (… compile) and check for errors. If everything seems fine, call is in your browser.
First call the server page in the normal way. It should show the HTML code from the painted screen. Then change the address to “myusp.hello_browser”.
If this works for you, then you took the first step into a better server page.
Familiar with HTML or not?!
At this point you will have to decide for yourself if this is an option for you or just CRAP! It demands you to have knowledge in building HTML code. Failing here should let you hit the brakes and say “ok, I gave it a try!” But if it feels not that tricky, then just head on- there is much more to explore.
Since you read this line, I assume you want more- fine … let’s go deeper then 😉
Putting it straight: Code should be/is capable of more than one function.
Compuware bound us to let a server page have only one display functionality. This is because you must draw the layout of the server page in the component editor and have no option of doing more than one layout. Paint it, compile it- finished. Unluckily this didn’t feed my needs so I started to live without it.
In the previous part of this how-to I introduced a method to do so. I didn’t mention, why this will do, so I better get it done now.
How the USP works
The server page consists of three main things to do its job: WEBGET, WEBGEN and $webinfo(“output”). (Don’t nail me for not mentioning header and input stuff as well as the other interesting buffers)
WEBGET takes care of all parameters that comes in from the web (CGI – common gateway interface … or just say web interface). Filling out fields in the browser puts the value back in your component fields. This voodoo is done by the webget statement in Uniface which also fires the triggers here and there. The idea of this is nice but doesn’t work with more than one layout and neither will it fill out our own fields and containers.
$WEBINFO(“output”) is the (mentioned main) buffer that is transferred to the web. Everything in this buffer will reach the browser. It doesn’t care about syntax, integrity or other stuff- it’s just the output buffer.
So, what do we need to get going? Only the $WEBINFO(“OUTPUT”). The rest is obsolete! (… yes, forget about this! You won’t need it) Doing so will save time and money 🙂
Instead of bugging around with the layout, just get used to store HTML layouts in external files or even the db (database). Then just load it, put it into $webinfo(“output”) and that’s all. No layout will be disrupted, scratched or lost! Uniface will have no hands on that any longer.
Next let’s have a look at the triggers. Uniface is definitely about triggers. We only want to look at the surface of that and skip all those triggers fired when using WEBGET (we don’t want to use it, remember?).
The normal path through the server page looks like:
The path is changed as we call an operation:
Anything else is to be invoked by your code (e.g. retrieve -> read trigger). Please be aware of that no field triggers will be fired due to no WEBGET! This also impacts the format triggers and other stuff like that. But that’s not as nasty as it sounds.
While working with data, we will need some entities for two reasons:
- To be able to compile (*doh*)
- To work with dynamic data in the entities
Let’s declare an entity in the painting. Switch to the SOURCE tab below and enter the following:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
Change the “myentity.model” to your desired entity and return to the component editor. Hit the refresh button in the bottom and suddenly your entity will appear. Make sure to modify its properties to ALL fields like in a service. This gives access to all possible fields and won’t cause any headaches like “yak, I forgot to declare the field!”.
Now you can work with the entity as you like. Be aware of that from now on, you are STATELESS- there is no hitlist any longer! No strings attached, no hidden catch- you are stateless! Retrieved data will be brought to you. If your retrieve profile results a 10.000 occs, then you get 10.000 occs 🙂
Let’s try it out! We will take your entity and let the contents of some fields pass through to your browser. Declare another operation in the previously started server page and let it look like:
;### Start the html header ###
Vhtmlcode = “<html><head><title>Hello entity</title></head><body>”
;### amend a row per occ ###
While ($status > 0)
Vhtmlcode = $concat(vhtmlcode,field.myentity,”<br />”)
Setocc “myentity”,$curocc(“myentity”) +1
;### finish the html code ###
Vhtmlcode = $concat(vhtmlcode, “</body></html>”)
;### feed the browser ###
$webinfo(“OUTPUT”) = Vhtmlcode
Finished with that? Fine! Hit [CTRL]+[F7] and RESTART your uRouter service! Since Uniface is a kind software, it buffers the loaded components from the last request (… that’s why I call it the BUFFERHOG, hehe!) After having done that, reload the server page in your browser and try out the new operation.
A few words about the browser
The browser is your client in this game! It will get your html code and try to do the job for you. Be sure to do some well formed html code which applies to the standards! Doing so will let you forget about special code for browser x which won’t work on browser y. Do it once and let it fit to the standard.
There are a bunch of fine browsers out there to aim at. Personally I group them into categories. Those may be “The good ones” and “the rest”. Let me mention the group members for you:
The goods ones, who work fine and obey given standards, are:
- Mozilla (all sorts, all platforms)
- Webkit based (Safari, chrome, Konqueror and again : all platforms)
The rest at the moment just holds one name: Microsoft Internet Explorer!
- v5.x is scaring my pants off
- v6.x is creepy as hell (widgets are rendered in a strange way, fatally insecure)
- v7.x is at a level where you can say “ok …!” (but still insecure)
- v8 (not released yet) will not be a 100% but do better than the previous ones
Hear my advice: Take your HANDS OF IE6 and below! They will tear you apart if your project gets complex!
Personally I use Mozilla Firefox 3.x with the Firebug extension. To test my work with IE I use the “IE TAB” extension. Jason (Huggings) mentioned that there is a nice debugging tool for IE user as well. This works exactly like Firebug and is called “IE developer toolbar” available for download at Microsoft (or just put it to Google). Which browser you may choose is up to yourself!
Finally I must mention that there are a lot of further browsers out there. These claim to be the fastest, easiest and smartest because they can do “everything” and combine the features of the major browsers. Just skip those! They won’t help you at all. Here comes some reason:
1) Debugging is not, what they are best at! They will only let you surf!
2) Companies won’t use this! (They mostly use IE, then Firefox and perhaps Opera)
3) Try to Google any errata concerning those browsers! There’s not much to be found!
Conclusion on PART 02
Congrats, you made it to the end of PART 02! Try to fool around with the server page and see, how things behave with that! We learned how a server page works and how to expand the capabilities of it (U7(!), U8, U9). Further we figured how to use entities and talked about browsers obeying standards while others don’t give a damn 😉
HINT: find the updated article on http://www.udev.info