From: Ulrich T. <Ulr...@gm...> - 2005-09-04 12:17:10
|
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. 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. > > 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. 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. > > I think a choice of "not applicable" would be necessary for category2. > I would prefer method #1 since I'm lazy... ;) Such a category would not be necessary if we would have a separate table mentioned above. Zero entries would mean: no category fits. > it sounds good to me except for one thing: even if they are > applications, they could not be "stand alone" in the sense that they > could require external libraries (like WebUpdate which requires > wxHttpEngine)... maybe only "applications" is better ? 'applications' would be ok for me. > since the components are > 50 I would ask to everyone to consider carefully > the categories required for his components. Certainly. > Using the search page you can see all the unmaintained components. I'll take a look. > 1) think to IEHtmlWin, wxSpellChecker, wxXml2, wxScript, etc: they are > mainly wrappers for wxWidgets of external libraries / components. > maybe we should create a category like 'wrappers' ? Yes, that sounds good. > 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. 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'. (BTW: the initial version is now in CVS, and I think it's stable enough to create a file release as well.) > > P.S.: There are still problems with the display of component's web > > page. [...] > fixed both; thanks for reporting Great. Works perfectly now. Thank you. > > P.P.S.: For my new component wxPdfDocument I don't have screenshots, > > but I would like to show some example PDF documents. How should I > > handle this? > if they are small (in size; i.e. < 1 Mb) Currently about 256 kB. > I suggest you to put them in your "website" folder so they are > automatically synchronized with wxCode website. Otherwise, to avoid to > overload the CVS you should manually upload them in the "doc" folder > for your project at > > /home/groups/w/wx/wxcode/htdocs/documentation/wxpdfdoc I think this would be the best choice since these example files definitely do not need versioning > I think it will be easier for users of your component if you make > these third-party addons available in the wxCode releases... obviously > you can do this if this is allowed by these addons' licenses... These addons are LGPL as far as I know, so it would be certainly ok to put them in wxCode releases. But I think it would be best to make a separate ZIP file out of them since they will probably not change very often. Ulrich -- E-Mail privat: Ulr...@gm... E-Mail Studium: Ulr...@Fe... World Wide Web: http://www.stud.fernuni-hagen.de/q1471341 |