On Thursday 10 February 2011 18:44:48 Robert Schweikert wrote: > > This is probably the heart of the difference in the design approach. In > the system with the common lib, I as an implementer of a YaST module > depend on someone else to provide the functionality I need in > libyastcommon
Nope. Its you, the developer of the configuration task. With the current model of YaST modules we all have to do implement it already. So we just rely on ourselves ... nothing to worry. What used to be the "YaST module" is just the presentation of all this. (see my other eMail a few minutes ago) > Therefore, my implementation attempt requires me to > first know that I have to implement stuff in multiple places (more than > I would expect) and from a maintenance point of view I have to remember > 6 month or more down the road that my implementation is splattered about. This is how what we do currently as well. To solve one problem might require to implement functions within several modules. You might not even notice it but most current YaST modules are using parts of other modules - some just query data, some even change. > Not having the indirection of the common lib allows the module > implementer to nicely contain everything in one directory (2 if a GUI is > implemented). ... and would mean to lose the possiblity to offer a generic interface to both YaST and WebYaST. Both of them share the same common goals: - both do system configuration and management - both currently rely on YCP and want to get rid of it - both need an alternative way to do system configuration So why inventing something new in a way that only YaST can use it. And _if_ an interface would be added to the modules then WebYaST would rely on the YaST module directly - something we suffer from currently. Lets ratger depend on something that is light-weight, standardized and fast, and which can be used by the higher-level tools as they want. (WebYaST may only present a subset of the configuration options that YaST coult offer.) > Thus from a "casual" contributor and maintainer point of view I think a > design without common lib is more approachable. I disagree here. This approach seems to lead to a new SUSE-only solution again. Is this really something that we want? Then why doing such big changes in the first place? If its only us writing and maintaining modules we could stay with YCP. Maybe somebody likes to add some new functionlatity and call it YCP++. But this would not solve any of our real problems. > Well, beside the fact that I'd have to pick up YCP (the language) my > head was spinning after reading the tutorial for a few minutes because > of all the moving parts I had to consider for the module I wanted to > implement. My idea of doing this myself quickly deflated and I screamed > for help. Lucky me, someone was willing to answer the call for help. A > scenario like this shouldn't really be this difficult. Right, and it wont with the new system. You implement all you need to to in the CL layer. Everything you need to read, write and execute on the system to solve the problem - in one standardized language. You don't even need to think about the UI presentation as this is something that the "new kind of YaST" module does. Once the CL functions are implemented you can design a nice UI to configure all options/steps. From my point of view this is more easy than the current mixture of UI elements and system calls within the same YCP file. IMHO this is something that needs to be separated. We just learned about all the benefits of this approach when writing WebYaST in Rails. > - Your GUI code goes here: SOME_YaST-DIRECTORY > ~ import yast3.gui_elements > ~ use commonly known elements such as text area, buttons etc. > - Your backend code (code that touches configuration files) goes here: > SOME_OTHER_YaST-DIRECTORY inside a directory with a name to your > liking. > ~ Take a look at the API documents found here: SOME-LINK > and try to reuse existing modules as much as possible > ~ implement away and "Have a lot of Fun" :) > > There you go, MVC paradigm, 2 moving parts, 2 locations to implement code. When I look at my Rails apps I see all my Models collected in _ONE_ directory, in another I have all my Controllers collected in _ONE_ directory and I have all my Views collected in _ONE_ directory. With your approach we would have all models, all views all controllers spread around in mixed up in the modules directory. Is this really MVC like and is this easy to maintain and learn about? Thinking of models depending on other models, controllers using other controllers my head starts to spin around if I have to go and look them up on different places, maybe even search for them because its name does not indicate where it belongs (this is what we currently have with the YCP modules). I'd vote to bring the models together and offer a common lib. Ciao, Daniel -- J. Daniel Schmidt <[email protected]> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
