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

[Ulrich T. <Ulr...@gm...>]

Hi,

> 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). 

Exactly, since the relation between components and categories is 1 : n.

> 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. 

Why? In my view it is not more complicate to check one or more category 
check boxes than selecting two categories from list boxes. And if you 
do it directly on the database you write two inserts instead of one, 
and one of them is very simple having only the component name and the 
category name as values.

> 2) this would make the website even more complex and more than 2
> categories are not required I think. 

I don't think so. The size of the list of categories is not influenced 
by associating more than one or two categories to a component. And 
probably very few components will have more than one or two assicated 
categories, but in case a component fits in more categories the 
maintainer would be free to do so.

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

Sure. It's good to hear several opinions before deciding.

> 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. 

A solution enforcing a consistent category association would be 
preferable.

> 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). 

That's clearly an option, although it makes the application dependent 
on the MySQL database since the SET type is not SQL standard.

> > For wxPdfDocument I would like to have a category like 
> > 'printing/PDF/Postcript'.
> it seems too specific , for me...

You're right ... but when I wrote the mail I had no better idea.

> why don't use a category like 'print/export' ?

Excellent. To make it still a bit less specific we could call it 
'print/import/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' 

Sounds good. 

> I've just compiled it and it's very impressive ! optimal documentation
> & optimal organization. it built without any problem and everything
> works. 

That's good news. It's always a bit tensing when publishing code 
whether it will compile and work for others or whether anything is 
missing.

> 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... 

To be frank, it's not the only issue with MSVC6. 

As you mentioned it would be necessary to set the working directory 
when running the application from within MSVC (if you start it from the 
command prompt in the samples directory it works without problems. But 
there seems to be no way to do that using bakefiles.

Another problem arises when you build shared libraries (DLLs). The DLL 
is placed into the folder 'lib', but if you execute the application, 
the DLL is not found if it is not located in the samples folder or the 
lib folder is not contained in the PATH environment variable.

The third problem is not really a big problem, but a bit inconvenient: 
the warning level is set to 4 in the dsp files by bakefile. This leads 
to dozens of warnings which can savely be ignored, but it makes 
locating error messages more diffcult.

Maybe I should write a small readme file mentioning these issues.

Ulrich
-- 
E-Mail privat:  Ulr...@gm...
E-Mail Studium: Ulr...@Fe...
World Wide Web: http://www.stud.fernuni-hagen.de/q1471341