I confirm a great improvement in 9.4 beta regarding USP management. A nice work has been done to straighten things. If only there could be a way to just disable the annoying automatic html formatting...

For those who did not see the 9.4 preview at CU2008, this is just a quick note to clarify some of the Uniface web changes The structure/layout split productivity and usability improvements (i.e. no more synchronisation) of the integrated editor, will be in the DSP release of Uniface. The change applies to USP?s and the new DSP component type. DSP?s no longer use the {x}-tag server side instructions. This makes it very easy to use an external editor of your choice if desired. Binding fields between the structure and layout is a simple ?Copy & Paste?. To minimise migration effort/risk, USP?s continue to use the {x}-tag server side instructions. Uniface 9.3 USP?s, use the original synchronisation mechanism where the structure is driven by the layout.

Hi Laurent, a FAST fix (from the dITo-Group): Add a menu-item to ADDITIONAL. - dump the contents of the edit-field to a fixed file - run a sync spawn of the file (start associated app) - load the file contents back to the edit-field filedump theEditfiled,"C:\\edithtmlfile.axa" spawn "#C:\\edithtmlfile.axa" askmess "load modified data?" if ($status = 1) fileload "C:\\edithtmlfile.axa",theEditfiled endif Success, Uli P.S. please have a look at "UniAssist" on www.uli-merkel.de This application is driven by the middle-mouse-button and transfers text between uniface and an external editor. If it does not meet YOUR requirements (I tested it only with "normal" proc-code) we may work it out together.

Here goes a FULL ACK from my side! Its simply annoying and after all "obsolete"! They could cut the hole thing down and just let us handle entities+fields as like in Services and make me a very happy man with this. But back to your demand on an stable editor... I experienced the same, when i started off doing the web-stuff. So let me give some advise in order to make the Editor bow down for you: 1) NEVER NEVER EVER try to implement to many here and there! 2) NEVER EVEN THINK ABOUT to implement some nifty design in it 3) NEVER TRY to declare some above the BODY-Tag ( and finally DONT use webgen :) ... ) You now may think something like .oO(erhmm, well, if i don't do step 1-3 i'll never reach my goal!?) ... and maybe you'r right. BUT if you manage to live without it, then you'll be able to develop very nice web-stuff. Have a look at $webinfo("INPUT") and $webinfo("OUTPUT"). The only thing to do with this Uniface-NVU-WHAT-YOU-SEE-WILL-BE-LOST-IN-A-MINUTE-EDITOR is to declare your Entities! (And honestly- i don't do more with it. The code is written in the operations and entries aswell as in some triggers) Nothing more and nothing LESS! Thats a sad truth to tell your customer. But on the other half of it, you'll be the one to get paid doing the work. For me this enabled me to do stuff like: AJAX, widgets, Userdesigns and all the other stuff i used to do before i was placed in front of Uniface. Good Luck to you! -GHAN-

USP editor wanted ! I completeley agree with your point of view. PLEASE PLEASE PLEASE Compuware Do something, throw away this solution and turn back to a real standard externa Html editor like Dreamweaver. At least let developer edit USP structure as in services editor !!!

True ... i would even work with NOTEPAD.EXE! although an nice integration of HOMESITE (once allaire, then Macromedia and now adobe finally integrated it into Dreamweaver) would elevate me :) But lets get back to something realistic: A big help would be to simply turn it off! Nobody will get far, working with this tool. I guess, i'll have the chance to tell a bit about how i do @ CU2008 in amsterdam :) ... Cheers, -GHAN- BTW: Has anybody realised the security-flaws when using standard-editor-pages?! (at least i would define it as that) Its possible to call an USP with what-ever-parameters-values and they'll get interpreted by Uniface/Javascript and modify the produced code ... ;) The Procedure is pretty simple: Just call the USP via Browser and append the desired values to the painted fields. Uniface prefills the values and corrects the fieldnames with a number ... lets say a field is called "BEW_GR_ID.ADAUBEW_GR.AUDIT", the USP is called "MYUSP" and we open the path: http://what-so-ever/uniface/wrd/MYUSP?BEW_GR_ID.ADAUBEW_GR.AUDIT=HERE_GOES_MY_VALUE I tried this several times, but since i'm far from working in that way, i don't care about it. Have an eye on that while using those html-params ... ! TEST IT OUT! If this is a feature, then erhmm ... well ... personally i find this to be scaring! ... used U9.x back then in March 2008

Enhancement requests have been received and made for the layout editor. The results will be previewed at CU2008 (1st - 3rd Dec). Those attending the master class on day three will have the hands-on opportunity to play with the enhancements before the general release. In response to GHAN?s question/observation regarding query string security, what has been described is default behaviour. The pseudo behaviour of an empty execute trigger is: webget If (?no output generated?) ...webgen endif Without going into detail, in this case ?webget? will read / process the name value pairs in the query string (see uLibrary for a full description). As GHAN correctly points out, this may not always be desirable for HTTP GET requests therefore, you can simply look at REQUEST_METHOD in $webinfo(?WEBSERVERCONTEXT?), and generate a security violation for this condition e.g: if (request method is get) ...generate security violation page else ...default code (/ bespoke code) endif I?ve found that I never need to use GET type requests with the EXECUTE trigger, as I point all of these calls at operations. The default behaviour for USP html forms, is to POST to the EXECUTE trigger. This too can be easily changed to an operation if desired. In this case, I code the EXECUTE trigger to always be a security violation. Note: Before you consider changing the execute trigger on a USP, be sure you fully understand the default behavior and the associated execution and submission cycles.

Thanks for the fast coment on this, Jas Let me extend my post and reply to your comment. 1) POST vs GET I found, that i definitely use both methods to do the nifty things! I mostly use GET to do AJAX-Requests ;) ... and sometimes i POST them. And when i open different operations in my USP i'm able to put the desired URL in my Adressfield (Browser). POST requires having a form (method="post") or the AJAX-request to be configured to POST. For my way to handle things i made the following rule: - If there are no params on the request, then its a GET - Having params in a FORM-TAG turns it to be "POST" My USPs require to be flexible in that case. 2) Extending the test scenario Using the given method that Jason statet will surely prevent this, but just give it a try. i call it the SPOIL-THE-LAYOUT-Thing ;) HOW TO We take the same URL to call our USP: http://what-so-ever/uniface/wrd/MYUSP?BEW_GR_ID.ADAUBEW_GR.AUDIT=HERE_GOES_MY_VALUE now we append the same PARAMS with ".number" in the line :) http://what-so-ever/uniface/wrd/MYUSP?BEW_GR_ID.ADAUBEW_GR.AUDIT=HERE_GOES_MY_VALUE&BEW_GR_ID.ADAUBEW_GR.AUDIT.2=oNe_MoRE&BEW_GR_ID.ADAUBEW_GR.AUDIT.3=and%20again& BEW_GR_ID.ADAUBEW_GR.AUDIT.4=wohooow! This will get Uniface to produce MORE input fields than required. It doesn't matter if the field is a key field- it's simpy just produced and filled :)) LIMITATIONS even though the thought of putting a ".273" in the end of the fieldname of the request-string is worth a smile it WON'T WORK :) ... Uniface will only take the params given and produce content. Or to put it straight: TWO PARAMS (no matter what different number they'll have) = TWO FIELDS! This is surely not a big drama but has to be noticed! Most of those request with a "STORE" afterwards will end up as -300 ($procerror,"WRONG FIELD SYNTAX/Length") and deflect. So far from me in that case kind regards to you all -GHAN-

At CU2008 I've looked at the 9.4 editor for Dynamic Server Pages and get the 9.4 beta version. I think they have solved main problems of 9+Nvu. 1)You can insert fields and entities using "classic style" component editor 2)You can copy object (entities-fields-labels...) from DSP editor "as Html" and copy directly into HTML files 3)You can use an External editor instead of NVU. It's a pain that we have wait until dec 09 before we can use it as "official supported !"

Hi Andrea, just returned from CU2008 yesterday evening. While pushing the Uniface 9.3/9.4 Beta USP editor to the tests i confirm the functionality: 1) The USP-Editer seems stable and so reliable aswell 2) I don't need to "paint" my Entities any longer- just register them as usual in service components. 3) it was EASY to produce some DSP (dynamik server page) which is functional 4) Gertons shop-demo was nice and worked well The claims for an stable editor have been heard and i guess we dont have to wait until the release of 9.4 to forget about failed synchronisation and data loss! As they said (and i do believe it by now) : the editor should have been changed in 9.3 which actually is available :) Maybe not all testet functionality are the same as in 9.4 BETA but it should do. Please let me know if somebody could test and confirm this! If it FAILS i surely will get myself heard :) kind regards -GHAN- the one who is supposed to Have Another Name :))