i am doing some research to see if we can embed quicktimes into the xhtml for xhtml renderer, i found this in the docs:
ReplacedElementFactory The org.xhtmlrenderer.extend.ReplacedElementFactory provides XML- element replacement during the layout and render cycle. The most obvious use for this is for elements that point to content which is not itself part of the document, like ../images; with just an <img> element, the library has no way to actually render an image (or an icon, or whatever). To do this, it uses a ReplacedElementFactory, which resolves the <img> to, for example, an ImageIcon, and returns this (wrapped in an interface) as a pre-sized component that the library can render in-place. In our SVG demo, this same technique is used to render specific <object> elements referencing SVG data files as ../images in the document. It is also used to render XHTML form elements as Swing components when using the XHTMLPanel. For Swing (JPanel) output and for PDF output, there are already ReplacedElementFactories supplied for you. If you want to supply your own, you can do this by accessing the SharedContext for the panel or PDF renderer. For example, in the SVG demo, we use a "chained" REF which implements a chain of responsibility for multiple REFs, as ChainedReplacedElementFactory cef = new ChainedReplacedElementFactory(); cef.addFactory(new SwingReplacedElementFactory()); cef.addFactory(new SVGSalamanderReplacedElementFactory()); final XHTMLPanel panel = new XHTMLPanel(); panel.getSharedContext().setReplacedElementFactory(cef); If you code your own REF, note that this class will be called for each element in the document—it needs to be relatively lightweight and implement caching intelligently. _____ the question i have is how would it load the quicktime from the url? -Tony On Feb 1, 2008, at 7:59 AM, Scott Cytacki wrote: > > I wouldn't use mozswing for each question in a step at this point. > Hopefully in the future we can use it that way, but not yet. I also > would not count on mozswing becoming a lightweight component anytime > soon. We would like to make that happen but I think it is lower > priority than some other improvements we want to make to it. > > Any handling of Quicktime will have to be done with a heavyweight > component. To solve your current problem Tony, I would suggest > embedding mozswing inside of xhtmlrender to handle the flash. Last > time I worked with xhtmlrender it was possible to embed swing > components > inside. So mozswing could be embedded that way inside. I don't > remember the details of doing this embedding, and I think it has been > changed anyhow. > > Scott > > Stephen Bannasch wrote: >> At 3:50 PM -0800 1/31/08, Anthony Perritano wrote: >> >>> you mean for every question? say a self test step has 4 questions. >>> that would be 4 mozswing browsers imbed in the step? do you think >>> this >>> is practical? >>> >> >> I don't know. It was certainly the goal of the work to be able to >> do this. >> >> >>> mozswing is a heavy component right? it doesn't mix well with light >>> weight components in the container? >>> >> >> Yes, mozswing is a heavyweight component -- you are right about the >> UI problems. This should be fixed at some point also. >> >> For more info on how and when these fixes will be implemented Scott >> will need to add to this thread. >> >>> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
