1
0
-1

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?

    CommentAdd your comment...

    3 answers

    1.  
      1
      0
      -1

      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....




        CommentAdd your comment...
      1.  
        1
        0
        -1

        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:

        • Create new main development objects and automatically add them to the project.
        • Add existing main development objects to the current project.
        • Open or navigate to main development objects in the project.
        • Compile the objects belonging to the project. This compiles development objects and generates runtime objects.
        • Group development objects in a variety ways. For example, you can group objects to reflect the application architecture, as well as create ad-hoc projects that contain only the objects you are currently working on."

        Hope this helps.

        1. Iain Sharp

          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 ......

        2. Knut Dybendahl

          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?

        3. Iain Sharp

          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.... 


        4. Knut Dybendahl

          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...

        5. Iain Sharp

          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. 

        6. Knut Dybendahl

          I know you do - and we do too...  but the 'normal' developer would not... thus I was asking the question(s)...

        7. Gianni Sandigliano

          Hi all,

          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.

        CommentAdd your comment...
      2.  
        1
        0
        -1

        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.

          CommentAdd your comment...