Re: SUGGESTION: Make a two-level TDD file structure
Daniel Dekany <ddekany <at> freemail.hu>
2006-07-18 20:30:45 GMT
Tuesday, July 18, 2006, 8:26:36 PM, Colbert Philippe wrote:
SUGGESTION: Make a two-level TDD file structure for more abstraction power.
The TDD feature is one of the most powerful features of FMPP. TDD hierarchical structure lends itself to complex applications. That's great!
However, I find myself wanting a little bit more. I would like to see a two-level TDD file setup. That is I want to see two (2) different TDD files. The values of the first TDD file beeing used in the second TDD file (property interpolation) and the second TDD being the final TDD file to be used with FMPP.
This would greatly increase the power of FMPP. It's a natural extensition. For instance, my application simply create XML configuration files using FMPP. I have wrapped each reusable XML section into an FMPP macro. So values are replaced directly into the macro. My TDD file separates parameters by macros. I would need a second TDD file to have "application specific concept abstraction". That is grouping values by application concepts. This second two-level concept can be reused in any application and would make things easier and cleaner.
Let me go even one step further by generalizing this concept of levels of TDD file. Let me suggests that FMPP supports any number of cascading TDD files. Instead of limiting ourselves to two-leve, let's make it n-level TDD file cascading.
TDD file1 --> TDD file 2 --> ... TDD file N ---> Used by FMPP
The TDD file N is used by FMPP. The other files are forgotten. This would allow any number of levels of abstraction.
Good-old TDD bleeds from hundreds of wounds, huh? For example, what you say, if I understand your suggestion well at least, is a "deficiency" that is known for me. It should be solved purely on the TDD level. The TDD should have a line like:
# Note that of course you could use cvs(...) and whatnot.
and then the TDD language should allow referring to these variables somehow... don't know, for example with a sub(name) function. (Similarly, the inheritance that TDD config files can do, should be a TDD feature, not an FMPP config. loader feature.) Or you even wanted macro calls in the TDD file? This is how a simple config. file format could gradually become a 2nd programming language... :)
Now, I don't develop FMPP actively for while, as it is clearly stated on the index page as well. So, if you (or anybody) needs new features (as opposed to bugfixes, that I still do), I'm open to discuss proposals that then can be followed with proper quality patches. Or even giving admin rights to the project, if I find the person reliable and talented. Otherwise all I can say, that if I will ever write a next generation preprocessor tool (Is there a real demand for a such tool? I'm not sure...), I won't forget about these things.
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
fmpp-open mailing list
fmpp-open <at> lists.sourceforge.net