Re: [wxCode-users] wxCode categories (please ALL read)

[Francesco M. <f18...@ya...>]

Hi,

>>>1) select the same category for category1 and category2
>>
>>this is probably the best way. I would not make the PHP code even more
>>complex to handle a new ENUM value like "not applicable" since I
>>currently reused all the code to handle "category" also for
>>"category2" 
> 
> 
> Well, in the end it would be better to have a separate table in the 
> database for registering the categories of a component than two 
> category fields in the component table. This would solve most problems 
> which could arise from the current solution. It would not be a problem 
> to have a component belonging to only one category and it would not be 
> a problem to have a component belonging to more than two categories.
yes indeed. The best way would be to have a "categories" table and the components fields 
referring to the indexes of the right categories inside that table. This would avoid 
category duplication (like now where both "category" & "category2" are ENUMs with the same 
values).

However we should consider that
1) this will make more difficult for wxCode administrators to edit component categories 
when using the phpMyAdmin interface for editing, for example, unmaintained components.
2) this would make the website even more complex and more than 2 categories are not 
required I think.

In any case, before proceeding I would like to have also John's and Otto's opinions...

> 
> I know you said you are lazy, same with me. :-) 
;)


> But you should consider to invest a bit more time now to gain time in 
> the future. Let me know if you need assistance in respect to the 
> database part since I have many years of database experience.
ok, thanks.


>>>2) select miscelleaneous for category2 (which would be definitely 
>>>misleading)
>>
>>I agree that this must be avoided.
> 
> 
> How would you do that? A component maintainer could select 
> 'Miscellaneous' as the second category by purpose since his component 
> might provide aditional classes which don't fit into the selected 
> category1 and not any other specific category.
well, I meant that this must be avoided just telling maintainers not to abuse of the 
"miscellaneous" folder... I've added a small notice in the EDIT & COMPSUBMIT pages.


> In my opinion the best solution would be to provide on the "Edit 
> component" page a list of checkboxes for all available categories and 
> the maintainer checks all that apply.
another solution instead of using a different table for "categories" would be to use for 
the "category" field the SET type. this is what I'm doing currently for the wx ports, 
versions, and build system fields (which are rendered using listboxes but they could be 
rendered also with checkboxes).


>>2) some components, like "mmwx" or "awx" have many additional classes
>>inside them. I think the best thing would be to split them in single
>>components and use existing categories... but I think this will
>>require some work and maybe the authors do not agree... so which
>>category should be used for these ones if we remove "miscellaneous ? 
> 
> 
> If more than 2 categories could be associated to such components this 
> wouldn't be a problem any more, I guess. Otherwise we would end up with 
> a "miscellaneous" category whatever we call it.
unless we told the maintainers which want to indicate a single category to set both fields 
to the same value, as you suggested; this way would not require a "misc" category.


> Additionally I have a selfish argument against the 'miscellaneous' 
> category: my component wxPdfDocument would end up there. ;-)
:-)


> For wxPdfDocument I would like to have a category like 
> 'printing/PDF/Postcript'.
it seems too specific , for me... why don't use a category like 'print/export' ?
in this way the categories would be:


'window containers', 'dialogs', 'controls', 'window layout',
'networking', 'stream classes', 'database classes', 'miscellaneous',
'applications', 'tutorials/wxdocs' , 'data container', 'print/export',
'wrappers'



> (BTW: the initial version is now in CVS, and 
> I think it's stable enough to create a file release as well.)
I've just compiled it and it's very impressive !
optimal documentation & optimal organization.
it built without any problem and everything works.

The only issue: if you use MSVC6 to run the sample, then it will run with working 
directory the "build" folder. Unfortunately this cannot be set in the DSP / DSW files by 
bakefile since this setting is stored in the OPT file. This results in a crash of tutorial 
samples > 3 to open the 20k_c1.txt, etc files...

very complete and useful !


Francesco