Re: [Cdk-jchempaint] Drawing with Visitors

[Arvid <gog...@us...>]

You are right there is some missing code, I have included it bellow.
The 'modules' are like the SymbolTreeFactory in your branch as they are used
to build the RenderingModel and their structure should probably change.

The basic function of the modules is for reuse. While looping over the atoms
and bonds in the atom container and generating rendering elements you may
want to pass the atom/bond to a highlight module and to the basic drawing
module, here modules work ok. If you want to add isotope information it
might be better to extend the symbol drawing module with extra
functionality.

This raises the question on how to turn on and off thees different rendering
options in a more advanced application, you might have check boxes for
different options that can be checked/unchecked. This be no problem with the
model described above. I will rework the modules so they more closely match
what is described above and take in to account the order as described in
your second post.

I agree we should design for the functionality we need right now and not
what might be needed in the future.

    private RenderingModel generateRenderingModel( RenderingModel model ) {

        AbstractModule superModule = new AbstractModule() {

            @Override
            public IRenderingElement accept( IAtomContainer ac, IAtom atom,
                                             IRenderingElement element ) {

                return element;
            }

            @Override
            public IRenderingElement accept( IAtomContainer ac, IBond bond,
                                             IRenderingElement element ) {

                return element;
            }

            @Override
            public Renderer2DModel getModel() {

                return r2DModel;
            }
        };

        IRenderingModule modules =
                new AtomSymbolModule(
                    new BondModule(
                    new AtomModule(
                    superModule ) ) );
        if ( atomContainer == null )
            return model;

        for ( IBond bond : atomContainer.bonds() ) {
            model.add( modules.accept( atomContainer, bond, null ) );
        }
        for ( IAtom atom : atomContainer.atoms() ) {
            model.add( modules.accept( atomContainer, atom, null ) );
        }
}

On Fri, Oct 17, 2008 at 2:44 PM, gilleain torrance <
gil...@gm...> wrote:

> Hi again,
>
> The idea of using a Visitor pattern for rendering is attractive in
> many ways, but I have a gut feeling that it might lead to trouble. It
> is very hard to see, of course, but there is a tradeoff between
> anticipating all future needs (impossible, and expensive in terms of
> code complexity) and avoiding headaches. Obviously we want to avoid
> headaches! :)
>
> As far as I understand, the basic idea of a Visitor is as here :
> http://paste2.org/p/88034
>
> This code is the bare minimum for a drawing framework using a Visitor.
> A composite of DrawingElements is visited by a DrawVisitor, which uses
> a reference to a Graphics object to actually do the work.
>
> The nice things about the architecture is that you can then have a
> SWTDrawVisitor, that holds a reference to a GC object (the SWT
> equivalent of a Graphics).
>
> So, this is what Arvid's code is doing in his branch (in the
> renderer.elements and renderer.modules). I am not quite clear why
> IRenderingElements are passed to an "accept" method in the modules,
> along with either an IAtom or a IBond; but the basic principle is
> there.
>
> Some nice usages of Visitor might include things like:
>
>   diagram.accept(new HighlightVisitor(g, "N"));         // highlight
> all the nitrogens
>   diagram.accept(new DropShadowVisitor(g, 2.0));   // make a drop
> shadow shifted by 2 pixels
>
> okay, so that second one is a bit foolish, but the basic idea of a
> function object that knows how to traverse a Collection of Elements
> and then render them seems good.
>
> But! It might be that there are things that you can't do very easily,
> or at all efficiently, with such a system. Perhaps the solution would
> be to use the visitor functionality where appropriate, and internal
> methods where necessary.
>
> thoughts?
>
> gilleain
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Cdk-jchempaint mailing list
> Cdk...@li...
> https://lists.sourceforge.net/lists/listinfo/cdk-jchempaint
>