Re: HTML_Object

A driver / factory pattern sounds good, I think: $object = HTML_Element::factory('object'); // Loads and returns HTML_Element_object That, or just a set of bundled classes which can be called directly (ala. Date). $object = new HTML_Element_Object; Sounds good, I think. "Stefan Neufeind" <stefan@neufeind.net> wrote in message news:4086B04D.5749.45D1C9@localhost... > On 21 Apr 2004 at 15:11, Klaus Guenther wrote: > > > David Grant <david@grant.org.uk> wrote: > > > > > Aidan Lister wrote: > > > > The problem with HTML_Object is: It's a useful package, but not big > > enough > > > > on it's own. > > > > What should we do? > > > > > > > > My suggestion: > > > > Have a set of HTML based objects perhaps bundled into a single package > > > > (HTML_Elements maybe). > > > > > > > > This package could hold the HTML_Object package, a HTML_List (for > > generating > > > > ordered/unordered lists - something I've got lying around) package, a > > > > package for generating XHTML elements, and any other useful nibblets. > > > > > > > > What do people think? > > > > > > I think a collection for HTML elements is a good idea. Each element > > > could come in the form of an individual driver, each of which extends a > > > basic HTML element with the core attributes (as defined by the > > > standards). Writing a seperate class for each (X)HTML element is not > > > desirable, even when it is as potentially huge as the Object element. > > > > I fully agree. In the past, HTML_Image was rejected for the reason that it > > would be absurd to have a package for each HTML element. However, a few > > complex elements that do not warrant an individual package would be combined, > > it might be very interesting. Especially for elements like object and > > applet. > > Agreed, HTML_Element(s) seems fine. I just wonder if it's a good idea > to have each of these classes in a separate file (perfomance). But > this seems to be the only clean and extensible solution, right? > > Stefan