Ralph Schindler-2 wrote: > > The alternate naming facilities are in place, the only problem is that > nothing exposes them yet (this is a matter of finding the use case). > The only use case that myself and Benjamin came up with was to let thing > work with existing project... which brings me to the next point. >
Well my uses case is that some of the naming conventions for structures within Zend dont work for me. My main complaint here is with the optional structures. For example, in my opinion "styles" should be "css" and "scripts" should be "js" or "javascripts". 1.) ZF isnt the only framework we use - I also use Symfony heavily, as well as an older cusom built framework. While asking for synonymous naming across the board is nonsensical its good to have similar conventions where it makes sense (ie. css and js and uploads directories). 2.) I feel the default naming of "styles" and "scripts" is ambiguous. "scripts" is used throughout ZF for other things generally and there may be other tyes of scripts beyond JS that would need to be publically accessible. Same thing with styles really - what if ive got public xsl's or something else that might logically be considered "styles". I suppose at this point if either of these were true it might be wise to simply nest the specific directories under their respective parents by type, but then in the more simplistic cases that makes no sense. So some flexibility here is good. 3.) Some of these namings outside of the actual application itself are a matter of preference as there is currently no direct automated integration or "look-for" location currently within ZF. This its pretty much up to the developer to apply their own conventions across all their projects or on a per project basis - thus they should be configurable. > Existing projects are higher on my list now that all other new features > are out the door. As you can imagine, scanning files and determining > their context is not an easy task. I'll start thinking about this. > Well for me personally i dont need automatic scanning. Manually editing the .zfproject.xml to tag the existing structure appropriately and then running some kind of import/validate task is fine with me. What i think im really lacking is a clear cut explanation of how to craft this file by hand for re-use for our default project structure. Documentation on what every element is and does as well as having an XSD to reference would be more than enough for me. (perhaps these exist and ive overlooked them?) Beyond that i think simply having an interactive setup wizard that asks you things like "What is the path to the application directory?" and what not is good enough. This way you could simply answer questions regarding your existing structure and have the Tool build the proper XML based on the answers you give. > Alternate config type- by this I assume you mean XML? > Yes. I am very much in the "anti-ini" camp and use XML exclusively :-) XML is much easier to use and decipher, especially on large projects where tons of settings are nested - plus its easier to manipulate and validate (xsd, xslt). For smaller, simpler projects thats a non-issue but still INI is hard on the eyes to read and configure and it also has a tendency to lead to a lot of repetition for nested structures. If YAML support was available i would most likely use that for simple projects while still sticking with XML on larger ones. Currently, I have copy of the XML version of the default basic config and index.php in SVN and I just do a copy/export into a new project and replace the INI based versions. This works, but id rather just have it built in to the tool so i dont have to personally manage changes would be great. -- View this message in context: http://n4.nabble.com/Zend-Tool-in-1-10-tp964363p974905.html Sent from the Zend Framework mailing list archive at Nabble.com.
