Thank you, Jim, for your candid input. I appreciate it completely. I
also understand your concerns relative to the differences between Inline
and Standalone usage of Qooxdoo, and I agree that there might be issues
talking between javascript pieces in both halves. Actually, some of my
earlier comments were expressing this same thought, and I was hoping to
get some responses to confirm some of my suspicions.
However, the reason I'm concerned about a Qooxdoo bug is because
clicking and typing in the second textfield doesn't trigger the close of
the table opened by the first textfield. Both textfields are defined
and controlled from within Qooxdoo. Why would Qooxdoo not know that it
needs to close the table from the first textfield when I click and type
in the second textfield?
As a test, I will create a Standalone application and apply the same
textfield and table popups in that environment to determine if the
problem is with the popup widgets or with the use as Inline components.
This is probably a good idea for the sake of helping the Qooxdoo
deveopment team, and it's a good exercise for me to go through as well.
Again, everyone's input has been very helpful. I'm sure to use Qooxdoo
in some standalone instances as my use of it grows, but this particular
functionality needs to be applied within an existing page, at least for
now.
Thanks all,
Gene
On Fri, 2009-03-13 at 17:19 -0700, Jim Hunter wrote:
> The answer to your question about child objects in the DOM, is no. The
> only time one object is a child of another is if you 'addChild' it to
> another object. Just because one object calls the show() method of
> another does not make the second object a child of the first. The two
> have nothing to do with each other unless you added one to another.
>
>
> You keep trying to compare your behavior to the behavior of the demo
> program and I keep saying that you are comparing apples and oranges.
> In the case of the demo browser the "entire page is a qooxdoo control"
> and in your case "only the edit fields and the table are qooxdoo
> controls". You are missing how big this difference is. When you add a
> qooxdoo control to a standard HTML page using the inline method, your
> controls are islands on the page. They are not isolated islands as you
> have access to other objects on the page via DOM calls but qooxdoo is
> not managing those objects so it does not know when you click on the
> main page. And if it does not know when you click on that page then
> you can't create qooxdoo methods to react to them. If you create some
> standard JavaScript on the main page that reacts to the clicks, then
> calls methods on the qooxdoo controls, then you might be able to make
> it work. But you are going to have to work in both areas, the qooxdoo
> arena and the main page arena. This is not standard practice so you
> are not going to find a bunch of people on this list that have answers
> for you because it simply doesn't happen every day.
>
>
> And no, I don't see any behavior you are describing as a bug in
> qooxdoo. You are expecting qooxdoo to manage and react to things that
> it doesn't and can't. The reason you see the first table close when
> you move to the second table is because qooxdoo is aware of the move
> so your methods are getting executed. When you move to other parts of
> the page, the only event that might get fired is the blur event since
> it is a standard DOM event. But I can't even guarantee you that will
> work. Qooxdoo was designed from the ground up to be a full page
> application framework. The inline ability was added for those few
> instance where you wanted to use one or two static qooxdoo controls on
> a page. If you are going to be using lots of them then you should
> rethink the page and do it entirely in qooxdoo.
>
>
> I am not saying that you can't do what you want, it's just that I
> don't think anyone on this list has done it before so some creative
> thinking might have to be used in order to make it all work.
>
>
> Jim
>
>
> On Fri, Mar 13, 2009 at 4:51 PM, Gene Amtower <[email protected]>
> wrote:
>
> On Fri, 2009-03-13 at 18:05 -0400, Derrell Lipman wrote:
>
> >
> >
> >
> > I don't know what demo you are looking at, but on
> > the popup demo the objects, for me, stay visible
> > until I click on something. They don't close on
> > their own. And looking at the code, there is nothing
> > to tell it to close after a given amount of time.
> >
> >
> > Sorry I haven't been following this thread, so I may be
> > misinterpreting Jim's reply.
> >
> > There was a bug in qooxdoo a week or so ago that caused
> > context menus to go away as soon as the right button was
> > released. In order to select an item from the context menu,
> > it was necessary to hold down the right button, move the
> > mouse to the item to be selected, and left click while
> > holding down the right click. That bug has since been fixed,
> > but it may have been fixed after the recent release. I don't
> > recall. What Jim is describing as actions you're seeing
> > sounds a lot like what was happening with the context menus.
> > You might want ot make sure you're running current trunk and
> > not a version from more than a couple of days ago.
> >
> > Cheers,
> >
> > Derrell
> >
>
>
>
>
> Derrell,
>
> It's not obvious to me that this is related to my original
> question, which had to do with popup objects (in my case, a
> table that is displayed from a textfield event) not
> disappearing when I click on something else on my page. So,
> my problem is something NOT going away instead of something
> going away too soon. These seem quite opposite to me!
>
> For discussion, I downloaded 0.8.2 from Sourceforge.net on
> Wednesday morning around 9:00 am EST (or 2:00 pm GMT).
>
> Jim had some useful thoughts on how to work around the issue,
> but I'm still waiting for someone to tell me if my experience
> with my popup table staying visible is expected behavior or a
> bug in the framework, taking into account that I'm using an
> "Inline" implementation.
>
> Note that I have two textfields that each open a popup table.
> Something I have determined through trial-and-error is that if
> I get the first table open by typing in the first textfield, I
> can move focus to the second textfield and start typing,
> resulting in both popup tables being visible. When I move the
> focus into the second table, the first table THEN closes.
> This seems way too late to me. That's why I'm wondering if
> the framework has a bug. (Please note: I've talked in
> previous posts about how I have tried to add special event
> listeners that force the tables to close, but for these tests
> I had them commented out to duplicate the original problem
> (since they're not working correctly anyway).
>
> I added each textfield into a dedicated DIV tag for each
> textfield, and the popup object and the child table are
> instantiated from within the event listener with positioning
> relative to the textfield itself. I think this is consistent
> with how the demobrowser example implements the popup objects.
> Does this make the popup and child table objects children of
> their respective textfield objects in terms of the DOM
> structure?
>
> Thanks,
>
> Gene
>
>
>
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex
> Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities.
> Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based
> development
> software that enables intelligent coding and step-through
> debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-
> com
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________ qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
