Skip to main content

dITo: do IT ourself: Info request "Uniface 10 IDF" on LinkedIn, why not here?

  • November 19, 2018
  • 4 replies
  • 2 views
Jan Cees Boogaard

Info request "Uniface 10 IDF" on LinkedIn, why not here?

Author: ulrichmerkel@web.de (ulrich-merkel)

on Linkedin, Theo Neeskens started a poll in the

Uniface Professionals Network

:

How should the Uniface 10 IDF work?

posted 5 days ago • 19 votes

 
  •  

I commented:

A tool for state-of-the-art support of software development which can be expanded and customised in a way WE, the paying customers want to do our work.:

having the COMPLETE project in scope, not only the contents of one field in the repository. Minimum: All the code of a component on the screen.

The editor is aware of the existing objects and the syntax, so intellisense and autocomplete is possible (like XTEXT genereted editors).

The editor provides options for text-blocks including a dialog to map parameters of this snippet. (there are a couple of products on the market).

Having features to link in own customisations and add-ins. Like a routine to open the editor for a given object like $ude("openedit","COMPONENT","MYABCFORM",...)

An IDF providing hooks or "user exits" which allow us to link additional processing into let's say the compile process to incorporate just-in-time infos or start regression tests.

Uli

BTW: Why this is not started from uniface.info, so the complete community can participate?

 

and another one:

Ulrich-R Merkel • ... and it's not the buttons & controls, but the functionality and flexibility and ease of costomisation.

Unfortunately, your categories stay on the surface. Think this is the CPWR problem: instead of making a more usable screwdriver, they produce screwdrivers in fashion colours.


 

4 replies

Jan Cees Boogaard

Info request "Uniface 10 IDF" on LinkedIn, why not here?

Author: ulrichmerkel@web.de (ulrich-merkel)

on Linkedin, Theo Neeskens started a poll in the

Uniface Professionals Network

:

How should the Uniface 10 IDF work?

posted 5 days ago • 19 votes

 
  •  

I commented:

A tool for state-of-the-art support of software development which can be expanded and customised in a way WE, the paying customers want to do our work.:

having the COMPLETE project in scope, not only the contents of one field in the repository. Minimum: All the code of a component on the screen.

The editor is aware of the existing objects and the syntax, so intellisense and autocomplete is possible (like XTEXT genereted editors).

The editor provides options for text-blocks including a dialog to map parameters of this snippet. (there are a couple of products on the market).

Having features to link in own customisations and add-ins. Like a routine to open the editor for a given object like $ude("openedit","COMPONENT","MYABCFORM",...)

An IDF providing hooks or "user exits" which allow us to link additional processing into let's say the compile process to incorporate just-in-time infos or start regression tests.

Uli

BTW: Why this is not started from uniface.info, so the complete community can participate?

 

and another one:

Ulrich-R Merkel • ... and it's not the buttons & controls, but the functionality and flexibility and ease of costomisation.

Unfortunately, your categories stay on the surface. Think this is the CPWR problem: instead of making a more usable screwdriver, they produce screwdrivers in fashion colours.


 

 

Tatiana Andronache • Eclipse" Wavemaker? I don't even know what you're talking about...never have seen these products. My brief experience with Visual Studio was that it is a complex and complicated tool - steep learning curve. I don't want a new IDF with a learning curve because there is no or little [paid] time for it. My beef with the IDF is that there is still no way to automatically collect elements that have been changed and need to be promoted. It's pen&paper (or maybe I am missing something)? This, from the deep tranches of production, from someone who has a life beyond being an [old] U developer.


Ian Shankster • I use both Eclipse and Visual Studio and it would be great to try and integrate some of the features found in these tools with the new UDE. However, one of my major concerns with the current UDE is that because it is only possible to open a single component at once and library objects in open in modal window most developers find themselves having to open multiple UDEs. I would love to see the new UDE support non-modal windows everywhere.

Additionally it would be great to have the ability to create an XML respository which could be source code controlled directly, without the need for import/export (like the March Hare product offers), but I realise this might be asking too much!


Theo Neeskens • Hi Tatiana,
I think you have a point when talking about collecting changed objects. What do we need here? Selecting objects modified after a certain date and:
* Add them to a deployment archive

* Export them

* Compile them (possible already on the command line)

Did I forget anything?


Tatiana Andronache • Theo, I don't know how other shops handle promotion of items to the next environment; the only way I've seen is export every form, message and variable as an independent file. It is up to the developer to keep track of what was change and make sure all changes are promoted and there is no IDF assistance for that. Only the source is exported and we do not use deployment archives. The separation of duties is sacrosanct, i.e. developer does not administer production source code.


Theo Neeskens • So as a minimum you would like to be able to select objects that have been modified after a certain date for export?


Tatiana Andronache • Yes. I would also like to see the comment I entered on the day I made the change to the item. In the absence of native version control, some metadata capability will help a lot.


Ulrich-R Merkel • Hi Tatiana, because CPWR does not provide this option, a lot of uniface customers have build their own components to do this job. The Metadictionary and $ude or "icomp" provides all whats needed to be independend from "the lab" if it comed to IDF enrichment.

Even if it looks not "professional" because they do not cry for donations, some of them has published their codes free-of-charge on the internet.


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

Info request "Uniface 10 IDF" on LinkedIn, why not here?

Author: ulrichmerkel@web.de (ulrich-merkel)

on Linkedin, Theo Neeskens started a poll in the

Uniface Professionals Network

:

How should the Uniface 10 IDF work?

posted 5 days ago • 19 votes

 
  •  

I commented:

A tool for state-of-the-art support of software development which can be expanded and customised in a way WE, the paying customers want to do our work.:

having the COMPLETE project in scope, not only the contents of one field in the repository. Minimum: All the code of a component on the screen.

The editor is aware of the existing objects and the syntax, so intellisense and autocomplete is possible (like XTEXT genereted editors).

The editor provides options for text-blocks including a dialog to map parameters of this snippet. (there are a couple of products on the market).

Having features to link in own customisations and add-ins. Like a routine to open the editor for a given object like $ude("openedit","COMPONENT","MYABCFORM",...)

An IDF providing hooks or "user exits" which allow us to link additional processing into let's say the compile process to incorporate just-in-time infos or start regression tests.

Uli

BTW: Why this is not started from uniface.info, so the complete community can participate?

 

and another one:

Ulrich-R Merkel • ... and it's not the buttons & controls, but the functionality and flexibility and ease of costomisation.

Unfortunately, your categories stay on the surface. Think this is the CPWR problem: instead of making a more usable screwdriver, they produce screwdrivers in fashion colours.


 

Gianni Sandigliano • If the "IDF done with Uniface" path is already chosen trying to move top-down from larger views to detail my thoughts are:
0) I agree with the idea that IDF MUST be a reference application!
1) Software Development is structured in projects. U is used to manage projects very different in size and scope. Analyzing how the concept of project intersect the usage of U objects (someone call it Uniface DOM = Document Object Model) enable to recognize usage pattern of the U product. Knowing how the product is used enable to recognize what are the needs for the common U developer.
2) IDF should force all objects to be collected in libraries or modules. Libraries & Modules could be organized in tree to enable any composition of subprojects/projects. Objects could be easily moved from one library/module to another to restructure big projects on changed needs.
3) Web means mainly 3tier and in a 3tier environment front-end COULD be directly coupled with backend.
3a) It's shoudl be added a new property for entity objects that overrule the "frame within frame"; this property should indicate the relationship the runtime should use to connect two entities together. This is a simple way to enable the connection at development time of two frames not physically designed one within the other.
3b) Logical entities in the external structure could be assigned at runtime to physical entities.
4) Navigation: all U objects in the repository should be available from all specific development context
5) Search: all U objects in the repository should be searchable from all specific development context looking for properties or for code within triggers
6) Code autocompletition: YES, Uli is right...I agree with him. Every instruction should have:
6a) proposal to complete the code
6b) help in line with real working examples
6c) search to look for other usages of same instruction within current repo
7) Open hooks within IDF: to enable people to adapt the development to their needs.

Just other 2cents!

 

Arnd Ohlenbusch • First of all I think this discussion needs a wider range - so I think LinkedIn is the wrong place - it should be on uniface.info.

To the IDF itself, I think it is the best for Compuware (and for us) to stay on the Uniface IDF with the requested enhacements. I am affraid of getting e.g. Eclipse, because it is a lot of work to get the "uniface dev way" to Eclipse. Eclipse is just a nice framework. All the recomended functionallity are not out of the box (e.g. parameter checks, ...), they have to be impelemnted by Compuware. This takes some time. And if I look at the wishlist, I come to the conclusion that time is that what Compuware needs most.
The argument "people from university know Eclipse" is right, but how much does it help to build a uniface application - I would say almost nothing.
So please guys, go for the needed IDF enhacements and take the rest of the time to develop the MUST HAVE GUI enhancements -> this will be the best for all of us!!!!!


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

Info request "Uniface 10 IDF" on LinkedIn, why not here?

Author: ulrichmerkel@web.de (ulrich-merkel)

on Linkedin, Theo Neeskens started a poll in the

Uniface Professionals Network

:

How should the Uniface 10 IDF work?

posted 5 days ago • 19 votes

 
  •  

I commented:

A tool for state-of-the-art support of software development which can be expanded and customised in a way WE, the paying customers want to do our work.:

having the COMPLETE project in scope, not only the contents of one field in the repository. Minimum: All the code of a component on the screen.

The editor is aware of the existing objects and the syntax, so intellisense and autocomplete is possible (like XTEXT genereted editors).

The editor provides options for text-blocks including a dialog to map parameters of this snippet. (there are a couple of products on the market).

Having features to link in own customisations and add-ins. Like a routine to open the editor for a given object like $ude("openedit","COMPONENT","MYABCFORM",...)

An IDF providing hooks or "user exits" which allow us to link additional processing into let's say the compile process to incorporate just-in-time infos or start regression tests.

Uli

BTW: Why this is not started from uniface.info, so the complete community can participate?

 

and another one:

Ulrich-R Merkel • ... and it's not the buttons & controls, but the functionality and flexibility and ease of costomisation.

Unfortunately, your categories stay on the surface. Think this is the CPWR problem: instead of making a more usable screwdriver, they produce screwdrivers in fashion colours.


 

... for taking an active role in this discussion. It's a great "user experience".


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

Info request "Uniface 10 IDF" on LinkedIn, why not here?

Author: ulrichmerkel@web.de (ulrich-merkel)

on Linkedin, Theo Neeskens started a poll in the

Uniface Professionals Network

:

How should the Uniface 10 IDF work?

posted 5 days ago • 19 votes

 
  •  

I commented:

A tool for state-of-the-art support of software development which can be expanded and customised in a way WE, the paying customers want to do our work.:

having the COMPLETE project in scope, not only the contents of one field in the repository. Minimum: All the code of a component on the screen.

The editor is aware of the existing objects and the syntax, so intellisense and autocomplete is possible (like XTEXT genereted editors).

The editor provides options for text-blocks including a dialog to map parameters of this snippet. (there are a couple of products on the market).

Having features to link in own customisations and add-ins. Like a routine to open the editor for a given object like $ude("openedit","COMPONENT","MYABCFORM",...)

An IDF providing hooks or "user exits" which allow us to link additional processing into let's say the compile process to incorporate just-in-time infos or start regression tests.

Uli

BTW: Why this is not started from uniface.info, so the complete community can participate?

 

and another one:

Ulrich-R Merkel • ... and it's not the buttons & controls, but the functionality and flexibility and ease of costomisation.

Unfortunately, your categories stay on the surface. Think this is the CPWR problem: instead of making a more usable screwdriver, they produce screwdrivers in fashion colours.


 

Gianni Sandigliano • In my opinion "consistency with the past" is a (great) value because AFAIK the Uniface User Base isn't growth a lot in last decade...so, based on this concept, following the path of Uniface 7/8/9 with the (many) improvements requested from Uli is probably the first choice...Personally I would like to have Uniface Development integrated within Eclipse because almost ALL student today are exiting from University with Eclipse knowledge and many could be the possible sinergies after the integration...Just my 2cents!

Theo Neeskens • Ofcourse a simple poll like this only scratches the surface. For me it is just a starting point for later, more detailed discussions.

Many separate details for Uniface 10 are being researched/prototyped/built at the moment. Intellisense and autocomplete were among the first things examined. Also navigation is studied seriously. For example: anything that you could theoretically click on to be taken there, should be clickable etc. For most of these details we have a pretty good insight in what Uniface developers want.

But at the moment we are discussing the "big picture" too. Should we just evolve our current IDF, should we look more towards the simplicity of modern web based tool, or should we try to match the richness and complexity of a Visual Studio or Eclipse based IDE? And that is what this poll is about.

Why ask this question here? Just because this is one of the many channels where we get our input. You will find many of my colleagues looking for opnions on user meetings, at customers visits, facebook and uniface.info the coming year.

 

Adrian Gosbell • Embedding with Eclipse, as per Gianni's suggestion is an idea that we've looked at, but it isn't really a feasible option.


Eclipse is a single user, file based tool. So converting what has been a multi-developer, relational database driven tool would be a seriously large project with a whole lot of challenges on the way. (performance, upgrade path for existing applications, etc, etc).

For exactly the reasons Gianni suggests Eclipse, we're going to take influences from it, and Visual Studio, as usability and simplicity are going to make it easier to get new developers productive with Uniface.

Current plans are that we'll build using Uniface, as we can leverage the productivity that it brings us. We also get the opportunity to deliver some additional functionality for customers, as we identify the needs for new features that we want to use, we can potentially productize those so all customers can benefit from them.

An 'old Unifacer' said something to me a few months ago that really made me think about one other point.. In the Uniface 6 and 7 days, the IDF was a useful reference application to demonstrate the capabilities of what Uniface can do. We need to get back into that way of thinking..


Ulrich-R Merkel • Hi Adrian, nice to read your opinion here.

But when I referenced eclipse as a development ecosystem, I do not care if the sources are held in files, databases or somewhere else.

It is the attempt to see software as a system of objects which are connected. So to create an index where lets say a proc is defined and give the user the ability to jump to this definition is independend if we would have a singleuser-filebased or multiuser-respository.

As an example: if I type "call " I should be supported by a list of any entry which can be called from here: local ones as well as globally defined in my current library as well as the fallback libraries plus their signature etc.

Still I see uniface as a tool which is used to develop software as efficient as possible. I would like to see you more commited to build a better tool (aka more efficient usable).

Limiting the editor to the scope of a single database field (called Trigger) snippet compared to "scope at least the sourcecode of the component" may show the problem area.
And another one: Why was it impossible for CPWR to make the autocomplete (the one with the TAB key) customisable by the user instead of a hardcoded implementation?


Adrian Gosbell • Thanks Ulrich, I was specifically responding to Gianni's Eclipse comments.

In regards to your auto complete question, I don't know why it was implemented that way, I'm assuming that as with all features, it's a choice made based on resources, time and what else is on the product backlog.


Ulrich-R Merkel • Yes, but I assume the prime goal should be for CPWR to deliver a tool which fits for the people using this to do their day-to-day work.
Resources or time should not be excuses for a lousy implementation or missing functionality.

Unfortunately, a lot of features (like "shortcut") suffer from this halfway implementation:
Loosing shortcuts after even a minor uniface upgrade is only one of it. Having only some 6 * 6 shortcuts available per workbench is the other.
This makes it useless for professional usage (which is a real pitty, because you could make this a real booster for working in different areas).

One could have implemented this as well as a multi-occurence form on USCUT where you could have "unlimited" shortcuts; and appending 1 or 2 description fields to USCUT could be used as a reminder what needs to be done. This way we would have a todo-list incorporated into the IDF. Our current situation is P(aper)&P(encil)% a lot of navigation.

I would have done it already, but unfortunately CPWR does not provide a $ude functionality to directly open the editor form for a given object.

This and a lot of other issues was part of my "open IDF" presentation for the german user group in Stuttgart a couple of years ago but nothing has happend. Some other issues where from the 7.2.04 champions meeting in Amsterdam much more years ago.

Therefore, I do not expect a real leap foreward in terms of usability and coders support in your IDF 10. And I know a lot of Uniface customers who prefer to edit the export file rather the IDF because of much better efficiency.


Author: ulrich-merkel (ulrichmerkel@web.de)
Still scrolling?
Ask a question
Terms & ConditionsAccessibility statement