I'm not abusing core with plugin, and I'm not using that. I've proposed to move the plugin core stuff to umit.plugin while the gui stuff should be placed directly inside umit.gui, because plugins are integrant part of umit gui so it's better to have the gui files merged there.
2009/2/27 Guilherme Polo <[email protected]>: > On Fri, Feb 27, 2009 at 10:12 AM, Guilherme Polo <[email protected]> wrote: >> On Fri, Feb 27, 2009 at 9:52 AM, Francesco Piccinno <[email protected]> >> wrote: >>> 2009/2/27 Rodolfo S. Carvalho <[email protected]>: >>>> On Fri, Feb 27, 2009 at 8:52 AM, Guilherme Polo <[email protected]> wrote: >>>>> Hi, >>>>> >>>>> Can we move to a cleaner namespace in umit ? I'm hoping to change it from: >>>>> >>>>> umitCore >>>>> umitCore.radialnet >>>>> umitGUI >>>>> umitGUI.radialnet >>>>> umitDB >>>>> umitInterfaceEditor >>>>> umitInterfaceEditor.selectborder >>>>> umitInventory >>>>> umitPlugin >>>>> >>>>> to: >>>>> >>>>> umit >>>>> umit.core >>>>> umit.core.radialnet >>>>> umit.gui >>>>> umit.gui.radialnet >>>>> umit.db >>>>> umit.interfaceeditor >>>>> umit.interfaceeditor.selectborder >>>>> umit.inventory >>>>> umit.plugin >>>> >>>> I agree totally with this structure. I like the idea of having a >>>> 'umit' central package. >>>> Additionaly, for UmitWeb, we can have the extra packages: >>>> >>>> umit.web >>>> umit.web.views >>>> >>> >>> Me too but I think that would be better that interfaceeditor is a leaf >>> of gui, like also inventory. For plugins i suggest that core and gui >>> part should be separetad, so the gui part will be included directly in >>> umit.gui while the core part will be umit.core.plugin. >> >> Uhm, maybe. But this kind of change requires better planning. >> umitInventory doesn't fit entirely into umitGUI, so I'm not sure why >> you are suggesting to it be entirely inside umit.gui. I also believe >> interfaceeditor doesn't fit entirely inside umitGUI, but I'm not >> suggesting anything since I haven't looked at its code. >> >> The first step is moving to a cleaner package structure, next we can >> decide how to restructure those packages -- if needed. >> > > Also, why continue the "abuse" in umit.core ? Why do you think > umitPlugins should get some code moved into umit.core ? umitCore > already contains an enough mix of core and non-core modules, please > lets not continue with this. I hope umit.core (or umitCore) at some > point only contain the real core modules, Email is certainly not one > of them, neither Scheduler things, neither Plugins things. > >>> The final >>> result should be: >>> >>> umit.core >>> umit.core.radialnet >>> umit.gui >>> umit.gui.radialnet >>> umit.db >>> umit.gui.editor >>> umit.gui.editor.selectborder >>> umit.inventory >>> umit.core.plugin >>> >>>>> >>>>> higwidgets stay as it is, except for some files. >>>>> higwidgets.higanimates for instance is nice, but how come that got >>>>> inside higwidgets ? For this kind of widgets we could add a >>>>> umit.gui.widgets. >>>> >>>> I guess higwidgets is a separated project, owned by Cleber, but we >>>> need to take a look on that. >>>> >>>>> >>>>> Then there is the remaining issue about the umit executable file and >>>>> this new umit package. We could move all the code currently in this >>>>> umit file to a module named main inside this new umit package. The >>>>> unix installer could then create a umit executable (which could be >>>>> either a shellscript that executes "python /path/to/umit/main.py" or >>>>> something else that imports main.py and run main(sys.argv)) at the >>>>> appropriated place. >>>>> >>>>> My motivation to do this namespace move is that Umit is limiting >>>>> itself to very few packages, files related to the scheduler could move >>>>> to another package, umitInventory could be split too (and it would be >>>>> good to so). I'm also planning to create something to merge >>>>> configuration files and it would live in another package, since I >>>>> don't think it makes much sense to place it in any of the existing >>>>> packages. >>>>> Another point to consider is that it pollutes site-packages for no good >>>>> reason. >>>>> >>>>> Regards, >>>>> >>>>> -- >>>>> -- Guilherme H. Polo Goncalves >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >>>>> CA >>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>>>> Enterprise >>>>> -Strategies to boost innovation and cut costs with open source >>>>> participation >>>>> -Receive a $600 discount off the registration fee with the source code: >>>>> SFAD >>>>> http://p.sf.net/sfu/XcvMzF8H >>>>> _______________________________________________ >>>>> Umit-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/umit-devel >>>>> >>>> >>>> >>>> Ok, +1 for the refactoring. We'll need to put some effort on it, but I >>>> think it'll worth it. >>>> -- >>>> Rodolfo Carvalho >>>> Web Developer >>>> [email protected] >>>> >>>> ------------------------------------------------------------------------------ >>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >>>> CA >>>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>>> Enterprise >>>> -Strategies to boost innovation and cut costs with open source >>>> participation >>>> -Receive a $600 discount off the registration fee with the source code: >>>> SFAD >>>> http://p.sf.net/sfu/XcvMzF8H >>>> _______________________________________________ >>>> Umit-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/umit-devel >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Francesco Piccinno >>> >> >> >> >> -- >> -- Guilherme H. Polo Goncalves >> > > > > -- > -- Guilherme H. Polo Goncalves > -- Best regards, Francesco Piccinno ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
