Matías Szeftel ha scritto: > Every one on wxCode could try this if is no too much hassle and offer it > as a download option. In the hope of having a nice users base. It would > be nice to have a nice packaging system for our wxWidgets applications. > I'll try to use it in the next wxARG release. Great, thanks!
This makes it possible for me to introduce a big topic which I already wanted to do :) Currently wxCode internals have some drawbacks: 1) administration is not as easy as it should be: approving new components takes various time and the current internal structure of wxCode website is not very easy-to-update / straightforward. 2) browsing the component list is not as fast as possible: except for the links at the top and at the bottom of the page (those to other categories of components) the content is still generated on-the-fly. Initially I thought to cache only the links (since generating that set of links is a _very_ slow operation) to allow the developer which uses the http://wxcode.sourceforge.net/edit.php page to immediately see his changes reflected on the component list page, without the need of waiting that some cron job on SF regenerates that page. However, I now realize that the infos of the components are not updated so often and that the entire contents of the complist.php page could easily be cached and refreshed only, say, once per day. 3) component infos are not in CVS: before my restructuring of wxCode the (very few) info characterizing each components were kept in the Readme.txt file which any component should have placed in its root folder. While this made impossible an automatic generation of nice web reports, it was more programmer-friendly than the current DB-driven solution because it allowed the developer to avoid to use the web interface at http://wxcode.sourceforge.net/edit.php to modify and/or keep updated the component infos. The file was kept in the source repository and thus when e.g. making a new release the programmer only had to modify the version number there. I don't know how many of you use http://wxcode.sourceforge.net/edit.php but I'd guess (not sure however) that many components have outdated infos also because of the lazyness of the programmer to update the wxCode internal DB. 4) programmers do not keep up2date their components / upload sources to CVS. [ 5) if you think I'm missing something else, please say your opinion... ] If we decide to solve problem #2, i.e. cache the components HTML description, then the wxWPM project may help us to partially solve #1, #3 problems providing the following (big IMO) advantages: 1) the component infos would be stored in the CVS in an XML-like format, i.e. as a wxWidgets package descriptor (WXP). A sample WXP file for my wxXml2 component is at: http://wxcode.svn.sourceforge.net/viewvc/wxcode/trunk/wxCode/components/wxxml2/build/wxxml2.wxp?view=markup having it in the CVS/SVN allows the developer to easily keep it updated. 2) the component list HTML pages could be easily created using 'wxp' command line program (just look at http://wxwpm.sourceforge.net/packages.php - it looks familiar, isn't it ;) ?), and thus also cached and regenerated anytime there's a change. Also, updating the website to e.g. a new look would be extremehely easy: just changing the "viewformat" used by the 'wxp' utility (while to change the look of the component list would currently require changing lots of PHP code). 3) it would simplify the wxCode website structure, because the DB should not be necessary anymore: from that WXP file (which also contains MORE INFO on the component rather than those currently contained ), the 'wxp' command line utility can generate the HTML description of the packages. Thus the wxCode PHP website should not query the DB anymore but rather use those cached HTML code snippets. 4) the maintainer of the component could create more easily the releases of his component. With the info taken from the WXP the 'wxp' utility is able to automatically create the .zip or .tar.gz excluding e.g. the object files, the CVS/.svn folders from the archive, etc. Those releases would automatically be directly usable as wxWidgets packages from the wxWPM Package Manager. The drawbacks of switching to the use of WXP files rather than the current DB solution: 1) administrators of wxCode should necessarily install 'wxp' utility to update the HTML descriptions and/or add new components 2) all the maintainers should keep the WXP file (and update it) in the repo of their components. What do you think? Are they acceptable? Looking forward to hear your opinion, Francesco ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ wxCode-users mailing list wxCode-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxcode-users
