Name Spaces

[eAndy]

I dont' understand why the default project is shaped the way it is especially given the way that code generation works.

If I put my classes under logicalView/LogicalModel the code generation puts all that crap as the namespace.

So I have to create a new root package and build my namespaces out from there.

Little whacky. Please tell me I'm wrong and that there's a simple mechanism for editing the namespace

[Eve]

Right click on a package, go down to package control and then click set namespace root.

This will basically mean that package will be the root level namespace and all packaged below that will correspond to a namespace in your file.

Simon

[eAndy]

Yes, I knew that. But I thought there might have been a way to modify it.

It would be nice if the default project was more reflective of how you need to structure your project to get code compiliation to work properly with the way namespaces works.

[Eve]

Fair enough but I don't think that everyone uses EA for the purposes of code generation.

If you want that as the default, then create a new model, set it up the way you want it and then use that model as a basis for all new models after that.  (The Model Project field in the new model dialogue.)

Simon

[sargasso]

I agree with eAndy on this.  We are somewhat constricted by what appears to be the java viewpoint that the package constrains/defines the namespace, adequately supported by the namespace root feature.

However, from the point of view of an EA user who feels that the model structure should be driven from a need to organise for communication reasons rather than code engineering reasons, constraining the namespace to the package name/path means we have to have a design model and a construction model that repeat the same information.

I like to structure the repository so that the model can be maintained to produce both design and construction views from the same base point.  IOW it should be possible to create code based on diagram content, not package content. (I appreciate what this means in terms of source file pathing etc etc.)

Secondly one of the problems we have is based on our use of .NET and its style of namespacing i.e. the namespace is a logical identifier, not constained by the component structure.  For example I can have n library components - all sharing the same namespace.  At the moment this means that we have to have EA packages all having the same name, reducing the efficiency of model navigation. (I believe, but am not sure, that java namespacing is strucurally constrained?).

I have not delved into what the standard says about this, but it would appear to me (20cents worth follows here) that the "proper" place for namespacing is in the component models and that it should be a logical attribute of a component rather than the result of the physical structure of the model.

Cest la vie.  What we have is soooooo much better than a plastic template and a pencil.

Bruce