On Tue, Oct 19, 2010 at 7:31 PM, Hansi Raber <su...@su...> wrote:
> hello!
>
>
>>
>> The whole pipeline is actually very extensible. Check out the
>> OutputProcessFactory, which allows you to specify an a target process. You
>> just need to implement your own, specify the supported input processes and
>> make sure that your target process is created in the OutputProcessFactory.
>>
>> Let me know if you have any question about this.
>>
>
> yes, the OutputProcessFactory is exactly were i made my modifications.
> currently this factory is "static", meaning that i can't specify 3rd party
> output targets, without recompiling xmlvm.
>
So if I understand you correct you would like to develop plugins that are
not directly baked into XMLVM but that can be put onto the classpath and
then loaded through reflection?
It would certainly be doable, but I am wondering, if this usecase makes
sense. Ideally you would just submit your target and all the code into
XMLVM. But granted, it could make it easier for people to develop plugins
for XMLVM as they don't have to submit directly to XMLVM.
However, such a plugin API would need to be somewhat stable and therefore
needs to be designed careful. And I am not sure if we are at a stage right
now were it makes sense to make that kind of investment.
Getting to the elephant in the room: Would you have an issue with submitting
your changes to XMLVM again?
>
> my question would be if you have thought about opening this part up, for
> instance by allowing users to specify other targets (e.g. js-jqueryui)
> from the command line. those could then be developed independently of
> xmlvm.
>
>
> at this point it is really more a hypothetical question, um... i'll ask
> again about this when i have a working
> prototype of what i'm trying to do....
>
>
>
> best,
> hansi.
>
>
|
