Re: Categories (was Re: [PEAR-DEV] New HTML Form class for PEAR)

"Stig S. Bakken" wrote: > > "Tomas V.V.Cox" wrote: > > > > Stig Sæther Bakken wrote: > > > > > > > > > > > > > Why not HTML_QForm, HTML_QuickForm or something like that? It's a > > > > > replacement for HTML_Form after all, so it shouldn't look like a > > > > > "sub-package", which IMHO HTML_Form_Quick would. > > > > > > > > > > > > > Umm.. didn't know it will be a replacement for Form. If it is so, > > > > HTML_Form would be the right choose, to don't break the convention :-? > > > > > > Uhm well, I meant a replacement [for the functionality provided by] > > > HTML_Form. If we want it to replace HTML_Form, it has to be > > > API-compatible etc, which may not be *cough* optimal. > > > > > > > So, if it's different and Ulf is creating his XML forms, why not create > > this new category? It's just a way to don't have the HTML dir full of > > form classes. > > Okay, we need to get the category concept straight before going any > further. > > IMHO categories should be given human/English names, such as "Database", > "Encryption" and so on instead of being based on package names. Sure, it should be so. >Their > only purpose is to provide categorization primarily for us humans, the > names and structure of the packages themselves is slightly different. Well, category names are human friendly, but IMHO still we need to map 1:1 "human categories" with "packages name spaces". Category -> Dir --------------------- Databases DB Foobiscus Foo If not, we will end with a package Bar in category "Network" but installed in directory XML/Net (for saying something). I see a mess in the horizon :-) > A "Forms" top-level category would probably be what we needed if there > is XML form stuff coming too. Top-level? Please explain me why top level and not sub-category of HTML. Tomas V.V.Cox