Re: DOM/javascript experienced programmer needed for simple task

From: Date: Tue, 14 Jan 2003 19:59:14 +0000
Subject: Re: DOM/javascript experienced programmer needed for simple task
References: 1 2  Groups: php.pear.dev php.pear.doc 
Request: Send a blank email to pear-dev+get-12429@lists.php.net to get a copy of this message
Just for the record, DSSSL is very flexible, but if you're not used to thinking Scheme, you'll have to go through great pains to get things done. When I wrote the first version of the phpdoc stylesheets in '97, that was at the end of a 20-hour deep hack. Since then I've been hesitant to touch it again, so I don't blame you. But DSSSL is _at least_ as powerful as XSL. - Stig On Tue, 2003-01-14 at 09:45, Alan Knowles wrote: > I just updated the documentation for dataobjects in peardoc2, while at > it, I felt that the unusual mix of static and inherited methods, meant > that the standard notation of DB_DataObject::method(), unfortunatly did > not really sit well with the package design, - The package is a little > unusual, in that some methods are static, some are only relivant to the > inherited methods.. etc. so I used > ->get(), in the title, and $DB_DataObject->get(......), for the function > reference. > DB_DataObject::staticGet() and {Child Class}::staticGet(), for some of > the rather odd static and inherited method > > have also added in some of the subsection introductions.. > > Overall it's not too bad, but it unfortunatly, the sense is that the > documentation for individual packages is dispearing, as you have to go > into the categories to find them.. I had quite a look at the dssl stuff, > (which all i can say is that "I'm not sure I ever want to touch it > again"). It appears that there are serious limitations in terms of how > you can layout the title and chapter pages. (which is a general problem > with dsssl, no idea how much simpler this would be with xslt) > > From a design view: > a) the lack of visiablitiy of the individual packages from the title > page is extremely annoying.. > - the only fix was to increase the toc-depth to 3, which ended up > showing all the PECL methods, and alot of the introduction stuff... (not > good either) > - otherwise all I could think of was to abandon the category > groupings for now, until someone is brave enough to have a go at xslt > generation.. (although this would have the additional benifit of giving > the individual packages the posibility for method grouping.. -- eg. > making the methods subsections of the classes, rather than flattened out > by the index...) > > b) the way the package section pages, list the contents of the first > package in the section along with the index is very distracting > (basically it's easy to miss that there are other packages in the category). > - is that an easy fix? > > c) the package section pages do not list package descriptions.. when we > have DB, DB_DataObject and MDB in the database chapter, a casual browser > will have no idea what they are.. > > > Otherwise, the 1 file/page per method, is an great improvement... > > Regards > Alan > > > > -- > Can you help out? > Need Consulting Services or Know of a Job? > http://www.akbkhome.com > >

« previous php.pear.dev (#12429) next »