On Thu, Apr 06, 2006 at 11:06:00PM -0700, Dan Fabulich wrote: > Good points there... Here's my two cents (and a bit). > > 0) Not explicitly highlighted, Selenium Core generates an XML file > with a full description of its API; this is enough information to > generate copious javadoc, ndoc, rdoc, pydoc, or POD perldoc. We should > use it for something perl-ish, one way or another.
Agreed. > 1) It's worth noting that the other drivers (java, c#, python, ruby) > *do* have build code. For python/ruby, there's just enough build code > to run XSLT to generate code, run some tests, and generate doc, but > the c# code requires running it through csc and the java code is > compiled by Maven. A makefile would therefore not be out of place. > > 2) As clever as the AUTOLOAD code is, it can be very opaque to end > users. Since the AUTOLOAD code has no explicit definition of "click" > (for example), users can't grep through the code for its > implementation, and they have to consult the Selenium website for > reference documentation. While we could use the Core XML to merely > generate POD documentation, at that point we're really 90% of the way > towards generating all of the Perl code, which I would probably > prefer. I'm not particularly concerned about this one way or another. Provided the documentation is there people can look at the source or not as they please. No doubt some poeple would prefer the minimal AUTOLOAD code and others the more explicit longhand. Since it is machine generated we are keeping DRY whichever way we go. > 3) It's never been clear to me what to do with code that is partly > Perl and partly something else. CPAN is full of pure Perl (or Perl + > C) projects, but Selenium will always be a multi-lingual project (for > the browser-side JavaScript alone, if not also the Java server). What > do people normally do with that kind of project? I don't see a problem with that sort of thing going on CPAN, at least not from that point of view, but I do wonder if it is worthwhile given that it will exist as part of Selenium itself. I suppose the advantage would be that it would be possible to use standard perl installation mantras to install Selenium. > 4) I'm happy to volunteer to maintain a *thin* Perl driver that does > not include its own back-end code. Such a driver should be no longer > and no more complex than the Python, Ruby, Java or C# drivers, and > can/should include automatically generated code/doc. If the project is > bigger than that, though, someone else will need to do it. What is the state of this at the moment? I need it now, otherwise I'll be using the Ruby driver ;-) I have some time to work on it at the moment, but I might not have in a few days. Luke mentioned he had the basics of something, and you have volunteered here. Is there something I can assist with? As far as strategy is concerned, I think this is the right way to go. I don't see any point in rewriting the Java code if it is doing everything necessary (I discovered I needed a fairly recent (or possibly just not ancient) version of java to get it to work), and being consistent with the other languages seems to provide many benefits. I'm on freenode #selenium if anyone wants to discuss this there. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
