I can't answer your question about why you are not getting the behavior you
are looking for because I have only seen the code from one edit box and one
table. If you provide the code for all four controls I would be happy to see
if I see something that might be tripping you up.
Jim
On Fri, Mar 13, 2009 at 7:36 PM, Gene Amtower <[email protected]> wrote:
> 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) arepowering
> Web 2.0 with engaging, cross-platform capabilities. Quickly andeasily build
> your RIAs with Flex Builder, the Eclipse(TM)based developmentsoftware 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
