Re: Translators

Hi Tor,

I see what you mean. I'm not very happy with names like HTMLSupport.
It sounds to me like OpenSupport but I can live with it. Thank you for the
clarifications.

tim

----- Original Message -----
From: "Tor Norbye" <[email protected]>
To: <[email protected]>
Sent: Saturday, October 12, 2002 7:15 PM
Subject: Re: Translators


> On Fri, 2002-10-11 at 23:36, Tim Lebedkov wrote:
> > Hi,
> >
> > I'd like to move
> >
> > org.netbeans.modules.tasklist.FormatTranslator
> > org.netbeans.modules.tasklist.AbstractTranslator
> > org.netbeans.modules.tasklist.HTMLSupport
> > org.netbeans.modules.tasklist.usertasks.KonHTMLSupport
> > org.netbeans.modules.tasklist.usertasks.iCalSupport
> > org.netbeans.modules.tasklist.usertasks.xCalSupport
> >
> > to a new package named org.netbeans.modules.tasklist.translators and
rename "*Support"-classes to "*Translator"
> >
> > 1. Can I do it?
>
> Can you explain why you want to do it?
>
> It's going to break module encapsulation. In particular, if you do this,
> then the tasklist editor module must depend on the translators module;
> but since the translators module contains usertask code, it has to
> depend on the usertask module. Thus, all the modules become
> interdependent.
>
> The way I've been thinking about it is that the modules.tasklist
> package contains general support code, which all modules depend on
> (this is the autoload/tasklist.jar module.)  This is where the
> FormatTranslator interface lives (along with the SPI support class,
> AbstractTranslator.)
>
> Then each module can define additional translators. In the case
> of the UserTasks module, it defines iCal and xCal formats - these
> deal with usertasks (e.g. attributes like start time and end time
> which make no sense in the editor scanning module context).
>
> As another example, the HTML exporter in TaskListView is tied
> to that class because it accesses private/internal data structures.
> If this is abstracted into a separate package you have to expose
> more of the implementation than is healthy.
>
> > 2. Should I use release34 branch or the main one?
>
> Use the trunk. The release34 branch should only be a merge-target;
> when 4.0 comes out we'll probably abandon it.
>
> > 3. If I use release34 branch will the changes also be made to the main
branch? Should I do it myself? Which CVS command?
>
> No, that's the whole point of branches - you work in isolation and it
> does not affect other branches/the trunk. Explicit merges are necessary.
>
> > 4. Is NB dev version good enough so I can use it for daily development
and work on the main branch?
>
> Yes, they are essentially identical. I usually merge to 3.4 immediately
> after committing to the trunk; both versions should be considered beta
> quality. (I'm soon ready to rearchitect for the public API so that we
> can declare beta; I just haven't had good hacking time in the weekends
> lately.)
>
> -- Tor
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>