Scope when extending forms [SOLVED]

Classic Servoy
1

I’m using the very useful extendsForm property in order to create simple 2 tier navigation, allowing me to edit each navigational element in only one place. I am, however, having trouble organising my forms into modules because whereas I can extend a solution-level form with a form from a module, I cannot do it the other way round (or between modules).

For example I have a form called nav_top containing the elements common to every form including the first level navigation buttons. I then have nav_, nav_ etc forms, each of which extends nav_top and contains the 2nd level buttons. This gives a lovely setup, and so-far-so-good.

At the final form level, each form extends it’s appropriate parent (e.g. nav_), which in turn extends the nav_top form. I want to arrange my solution into modules like this…

Solution

  • Login form
  • nav_top
  • nav_people
  • nav_account
  • nav_machine
  • etc
    People module
  • Add / Edit (extends nav_people) < but I can’t do this
  • Search (extends nav_people) < but I can’t do this either
  • etc.

I hope this makes sense, I really don’t want to have to put all my forms at one level.

2

Thanks to Rene from Ambitius, I have now solved this simply by specifying the module containing the templates in the moduleNames property of the module solution.

3

The concept of a module is that it can be standalone, it is a unit of stuff that has completely self sufficient.

So when you have

Solution A
Module B

and solution A has module B as its module

then Solution A can access everything from module B

But module B cant access anything from Solution A. Because if i now open module B as the main solution it should also work.

So solution A can create a new Form that extends a form from Module B
but Module B can never create a Form that extends a form from Solution A.

If you then say Module B has also Solution A as his module. Then the whole concept of a module is gone, Because what you just created is one big solution, that they are divided into modules doesn’t make much sense anymore
because it is one big thing if you view them from the outside.

4

Thanks Johan, my overall solution is highly integrated with little distinction between modules, and they can’t operate independently of one-another.
I’m therefore using modules purely to organise my development environment, I hope this makes sense?

5

Yes, Ben, it makes sense to organize forms in modules, if only to ease navigation between them.
In a team you would also have people dedicated to certain modules, being discrete part of a whole application.

And yes, Johan, it is one big solution if you had solution A as a module to module B, but it helps.
That way, module B is not really a module but a ‘sub part’ of solution A.
Still, when you have a solution with hundreds of forms all on the same level, it is a very handy way of keeping things organized.
You will say that you can filter or ctrl+shift+L to find your forms, but if everything is at the same level which should work discretely as a whole, it’s like trying to work in Java with all your classes in the same package: I doubt you would like that either! :)

6

i get that
but the thing is that modules are projects or jars in java…
thats how they map. And also with for example Eclipse projects, circular references should be avoided.