Uniface on GitHub
Fixes and Updates
We have imported forms into Uniface 10.3 from Uniface 9.7 and they are not listed under a project. When we create new forms or modify existing forms (or other objects) do they have to be under a project? How does having forms under a project influence how they are compiled, deployed and run?
The whole notion of a project is - I believe - in an established application, not worth the effort nor the time and money.
The fact I can have an established 'application' living outside of a project is great - thus it begs the question;
Why force new objects to be in a project?
That doesn't make any sense - especially since the new object ALWAYS will have to interact with objects outside of said "new" project.
Thus - a project is null and void in this particular case.
There are a lot of great / good new features (from a UF developer's perspective) in UF10 - imho - projects doesn't
fall into that category. Or - entirely possible as well - I haven't (yet) discovered a usefule case for using a project....
Adding to Iain's remarks:
At this moment there is no option to automatically add objects of an export file to a certain project when importing it into Uniface 10.3. It, however, is also not mandatory to add existing main development objects to a project. But if you want to create a new object then you need a project. See (e.g.) also:
> About Uniface > Uniface Development Paradigm > Projects
"A project is a collection of references to main development objects. It is used to create and organize components, modeled entities, and libraries that are needed to build the application.
You can use it to:
Hope this helps.
I've read that, here and in the original migration documents, and (I think) in the way back when either watched a webinar, or read a blog on this site about it, but it still doesn't answer my basic question about WHY you would find it useful to do any of those things.
What is a project practically used FOR in the development/deployment process? What does it allow you to do in a faster/easier manner than anything else? None of those declared abilities seems to have a purpose....
I just can't see the "User story" behind the function.
As a uniface developer
I want to group items in a project
In order to ......
Iain - 100% agree.
Why is this 'feature' giving us (the developers) such a massive 'benefit'?
I cannot for the life of me see any benefit of using a project. In fact, I believe it to be detrimental.
I haven't found any 'cross reference' anywhere to tell me that object "A" is used in project X, Y and Z - thus I have no visibility to changes to object "A" in project Z affects projects X and Y.
So, no - I don't get it.
Also - as an aside - since migrated applications / forms / objects don't belong to a 'project' - why shouldn't I be allowed to create a 'non-project' object?
Something like project specific $resources_output for example. So whenever a component was compiled it put copies in the three project folders/uars it was shared between, At it's base, we would then put all services in the services project, and all forms in the forms project etc to get smaller uar files for easier web distribution....
And when you do a model change (adding a field, changing a field) - all objects with said entity/field -
in all "projects".... Yeah - the picture doesn't get not pretty at that moment in time...
I do already have a component which will recompile all affected components/objects when an include/entity/etc is changed. What this would do is copy the compiled file (.frm & .sig) to the different uar's/folders so not a BIG change.
I know you do - and we do too... but the 'normal' developer would not... thus I was asking the question(s)...
I am a bit late into this discussion but I know companies, expecially VARs, which appreciate a lot the "project" concept. It enables to share a single repository and collect objects into projects corresponding to internal departments perimeter of competence.There were in the past other choices to accomplish the same solution? Yes, but I feel the collection of object into a project was (part of) what we need from a long time.
Obviously if you manage your (many) applications into a single installed environment the project concept is something not aligned with your choices.
We are currently only using projects (because we have to) to generate new objects. Having imported a mature system from 9.7, 95% of our components/entities do not have an associated project, and we do not suffer compared with 9.7 in comparison.
Our system is, however, always compiled in toto, so I don't know if it has benefits for people who maintain different distributions in the same repository.
© 2021 Uniface Privacy & Cookies | Privacy Statement | Legal