Hi,

I just took Andrews list of "each one half an hour" points.

And I looked at the information of the GRID1.ZIP and GRID2.ZIP Samples
readme files as recommended by Wolfgang.

Andrews points of work are not covered in the samples.
Nor is the helpfile designed to handle his requirements.

I do not want to get rid of the samples,
but there is a demand in the community for step-by-step instructions
how to build ones first grid widget including some possible variations.

One does not need to have a black belt to provide an example like this to the public
and an open-source screencast tool helps to transport the message.

Sometimes I record a webcast (Camtasia Studio 3) while I explain some issues to a colleague.
No extra effort spent, but maybe helpful to other colleagues just to have a 5 min TV edutainment.

Just do it, publish it on uniface.info, your own homepage or youtube and
someone may find it and find it useful (all the others don't count)

Success, Uli

'Good practices' could be, at least, concrete application sources, with comments, and technical/historical details hinting us about the good vs the bad -> to allow us to make our own opinion about adopting such practices. And as we are gentle people (sure we are, as we're working with uni ;-) we are not afraid of being told how to circumvent possible flaws of Uni...

On top of my head, some (possibly advanced) topics i have recurrently in mind:

• how the virtual machine is handling numerics ? As i'm doing some accounting i'd like to chirurgically handle the (usual) errors when operating (summing, rounding) amounts.
• i need some juice, sometimes: how the interpreter is translating the entity hierarchy into sql select request to the backend, how to adress requests to 6 or 7 entities at once ?
• how to handle small, medium, large code source for a form/service: because using the automatic event triggering is unreadable for big execution flows, i tend to bypass all of this to centralize and proceduralize when code grows for a form. For the sake of maintenance (readability/printability)
• etc.

Cheers,

Awen - back from vacation.

What is "best-practise"? It depends on the situation.  I've seen some uniface-projects with sometimes opposite Standards- and Guidelines. Here it is getting philosophic. If uniface declares something as "best practice", a couple of user have lots of examples and reasons of "why it can't be best practice". That is something, every team needs to decide for themselves, based on the project-goals (and experience).

I am thinking of an interesting marketing challenge for uniface:

If one day uniface offers his product to universities (or to any other) for free, they need at least a guide:

"How to develop an application within less than eight hours" (or six hours, or four hours   and zero knowledge in uniface).

A step by step description with necessary background-info beginning from the installation to a running micky-mouse-application, including asn-Files, templates, models, relationships, etc. If this guide exist and you can produce something within less a day of work, and without importing something pre-written, uniface has at least a good proof for "Rapid application building".

There are of course hundred ways of solving problems, and the guide can describe the 99 other ways as background-information ...

I guess, some projects did suffer on this missing guide.
 

W.

The samples in the quick reference or the on-line help are not the way you should program in Uniface.

For example: In a Component Based Development environment you should avoid the use of $1-$99  and $$variables.
The RIA example is a good example of bad practise programming. With other words: The manual should deliver not only how to write a Uniface statement, but should also explain best-practise.
Including naming conventions to avoid conflict for example declaring variables:

params
   string pName : IN
endParams

variables
   string vName
   numeric vStatus
endVariables

correct handle example:
vStatus = $instanceHandle()->xRetrieve("<xEntity>")

When they create a environment like building blocks in the past, Compuware can explain the Uniface way to develop. Imho a Model Driven Template Driven Component Based Development approach.

Regards

Dino Seelig - ITIS

   

Hi All,

From within Compuware, Uniface Training is now my responsibility.

We will not produce "a book", but the areas I am currently working in are:

1.  Online training for Uniface 9.4.  This, I believe, will be a topic based course that will provide a reasonably quick route to enable new people to discover the basics of "how to" with Uniface.  But it will also offer lots of "Learn More about..." and "Good Practice" pages.  That's where I hope to get help from this community - to provide those good ideas and best practices.  I am currently working to get internal agreement on the format and development.

2.  The other training that we currently provide, as instructor-led, is: What's New in Uniface 9; Uniface Environment Management; Uniface Web Developement; Uniface and Component Based Development; Uniface Advanced Developers Workshop.  All of these are being reviewed with the prospect of creating on-line training and, again, I would hope to open them up to the community.

I am keen that we produce training very soon after product releases but it will take time to refine this process. 

From all this I would hope that we will arrive, eventually, at the sort of knowledge base of which you speak but it will take time and about the only thing I can be sure of at the moment is that Uli is correct in his assumption that we will not get a massive increase in resources.

I will post progress as and when I have something worthwhile but please don't hesitate to contact me, either through this board or directly, if you have any specific query.

Dave

Hi,

just found a long-lost friend at http://march-hare.com.au/library/training/xmlstreams.htm

Tutorials ARE possible and they exist already,

Uli

Or we could do a FAQ again. About a century ago I contributed a small part to the FAQ of the Uniface mailing list (comp.soft-sys.app-builder.uniface).

I agree that with over 700 members we must surely collectively know pretty much all there is to know about Uniface.

One barrier to sharing this knowledge in an effective way is "not knowing what we know".

Once we work something out for ourselves often the temptation is to see (with hindsight) that as an easy gain and not worth sharing.

Another barrier is the disjoint in things we know vs an article worth publishing.

I had a good/bad example yesterday when I played with a grid widget for the 1st time (I know - dinosaur!)

I actually took me a while to figure:

• that an existing multi column/row tableau could easily be turned into a grid just by declaring the entity to be a grid
• that labelled column headings required labels for each column (doh!)
• that the labels had to be created fresh from the grid fields (and not renamed from the buttons from before the use of the grid)
• that the labels would only show if a good horizontal split bar protected them from the 'attach to top of window' for the grid itself
• that a command button inside the grid was always going to be visible no matter how many times the code hit it with a $fieldsyntax = "HID"
• that a command button inside the grid will not display a glyph !

Let's say that each of these little nuggets cost me half an hour (slow, plant-eating, dinosaur).  That is a process that will probably be repeated countless times.

So as well as a forum for big comprehensive samples/articles/white papers on the various subjects of interest we also need some buckets in which to collect these little nuggets of wisdom.

What I Know Is - it would be useful to have some editable content rather than just cumulative content pages - Anyone for a Wiki ?

We could start by having an on-line editable/extensible version of some of the sections of the latest ulibrary document.

Just my 2p

I stick with my original point of view.
Things should be so simple that I don't need a manual or example.

"The books" are normally the samples, which are on an Installation-CD, and will be installed during the normal installation process. 

Import the sample you need, follow up the descriptions, and learn of how-to. They are really good! You need at least the time to do so.

Possibly the samples are not the state of the art. I didn't check them for the themes I know already.

The reference in the help-file of uniface (getting newer samples) --> Page doesnot exist.

For uniface 9.4.Beta only the RIA sample seemes to be new. Anyway, the samples are giving me the basic information from where I can build the complete rest.

Wolfgang

Hello Uli,

based on your answer:

;y experiences are a bit different: 

(1) The samples are not pure code. If you open the html within the sample, you get a detailed description, some exercises and so on. There's the tutorial.

(2) These samples are definitly helpful for developers with less experience.

My 2c: uniface should follow up the strategy with the samples.

Wolfgang

Hi Awnen,

I do not see this community as some nuclear device which has not reached a "critical mass" even with 720+ members.

I think this is more a problem of "inert mass" and that it is easier to consume rather than to contribute.

But there is hope that under the 700 there are some 10 upright who just need some motivation to share their experiences.
I still try to stress the "why it may be possible" side instead of "why this is impossible".

I publish some under the "dITo" initiative and would like to see 1 or 2 contributions from others in this are as a start.

SUccess, Uli

P.S. I have problems with a "and in the meantime, we rely on CPWR".
In most cases this leads to a "lay back and wait until my wish is fullfilled"
instead of actively find some decent algorithms, I see indications for a "I give up, can only wait).

Hi Awen,

tutorials does not have to be always neat and brilliant.

in our scrum-and-sprint world, the following will do his job:

This is a post about scoping and how to use the EMF index for that. It is in some sense a practical follow up on another blog post about the general idea behind indexing and scoping in Xtext. The topic is somewhat advanced and bleeding edge. This post describes the needed steps to get the current index based default scoping up and running. I've prepared a small screencast demonstrating the result in action. The example language can be downloaded from here.

Success, Uli

... Because the community is not big enough for now to retribute willing people with enough consideration. i'm just assuming :-)

Because, as developpers, we're not comfortable in providing *smart* docs or courses for the others... Probably only a fraction of developpers are able and willing to do this on their spare(!) time, but for the time being, most of the contribution is going to be raw sources, day to day tools, some hints and answers... Crumbs of day work :)

Neat useful tutorial is another kettle of fish, and needs dedicated resources ?

cheers, Awen

Hi Awen,

good description of your viewpoint (it was not the beginner I had in mind, just someone who wants to use a treewidget).

But why "community doesnt have the critical mass(?) to generate documentation/courses spontaneously"?

All it takes after one has discovered the mystery of tree-widgets for himself (and spent some nights on it),
to put his experiments in an export file with some notes of his findings and infos used.

Place this fresh-from-the-workbench package as a contribution on uniface.info.
If your paper contains errors, you should deserve a friendly feedback.

If members do not like what one has done,
they should come up with something better
instead of telling one off.

Success, Uli

P.S. The important point is what WE can contribute here, not waiting always until the lab comes up.

I'm subscribing to this point of view: documentation samples are not... utterly... relevant.

Maybe samples are, concerning trees fe, but they're way too much specialized topics, for beginners.

I'm voting for progressive organised (searchable) tutorials, like Qt/Flex/SQLite (the last frameworks i had an eye on) are doing.

'Appropriate Uses' or 'Good practice' could be great too.

I'm telling this because i learned uni recently, therefore spent most of my time in old sources... I'm almost sure that i'm pursuing some of the bad practices of the great ancient before me :)

Uniface community doesnt have the critical mass(?) to generate documentation/courses spontaneously. So in the meantime, it's probably up to the Uni. team

cheers,

Awen

Hi Wolfgang,

As you stated, some samples are not state-of-the-art;
some other ends in a "page does not exist".

Because you work with uniface for a very long time, its easy for you:

Anyway, the samples are giving me the basic information from where I can build the complete rest.

But wouldn't it be better for the not-so-experienced if they have a
bit more support than the "naked" samplecode?

Compared with "cookbooks" and "tutorials" for other products,
the current situation can be handled much better.

Success, Uli