Table Tab

[Extra-Extra-Dev]

Hi Ian, Great work on the new Table feature coming along. I really like the embeded types ( just like lists ). Really swell.

I have this working on Windows and Flash, but the table fails to render for HTML5. I would like to confirm the status of that feature and/or what work I could offer if any.

Thanks for your great work.

[Extra-Extra-Dev]

Actually I see that Test2 xml does have a working HTML5 table. very nice... although I see column issues. Any comment as to best practice, then?

[ianharrigan]

Hey,

there is no real best practice for now. The whole thing was just a quick test to see whats possible. Im hoping to get some dedicated time this weekend on it, for now i would just try and deal with it as it is. If you are using xml, then you will probably be shielded from changes, if you are using it from code then, well, i just wouldnt... :)

Like i said, im hoping to get some free time this weekend and tableview is one of the top things on my list to come back to and do again properly. (column headers, etc, etc)

Feature suggestions are more than welcome!

Cheers, Ian

[Extra-Extra-Dev]

I am currently learning and working with your XML markups -- and not so much in-code, just yet. I was just diving in to see how to define column widths ( as I see your code test looping 20 items the columns didn't align ). Since how it is WIP -- is your goal to be able to do column definitions from the XML? Naturally, that would be a sweet, if not required(!), feature.

But yes, I could tell from the check-ins that it's work in progress :-) . And on this, you have my undivided attention on it (tables), specifically .. HTML5 output... ( read: I'm totally looking over your shoulder ). hahahahah As you say, it's seems a tad hit or miss yet-- but seeing even Test2 render a table from code ( not using XML/json markup ) and render to HTML was a sweet thing to see and showed progress. I can't get a table to render HTML5 using the XML/JSON markup, though -- which is slightly opposite of what you are stating. But either way, progress.

I am new to Haxe and in my evaluation of HaxeUI I am learning everything at once. My concerns are ( as most anyone) function and speed. So.. I was just about to audit your new TableView code to audit your approach -- as the loop20 test didn't have columns that align. Doing a QUICK review.. I see that SyncUI loops over the entire data source and makes objects. Is that true? If so, or even if not, let me take a moment to echo a smart Flex framework approach -- It may help with the column alignment issue and be the perfect time to bring it up.

If I'm not mistaken, the only way to truely have a datagrid (or list!) scale to any size datasource --- is to not expect the component to render every row of data for the view ( and then depend on scroll area masking for whats hanging off the edge of the area). The would make the UI far to heavy, say, if the collection is 1000's of records long. So Flex gains speed by having the (list) control(s) render as many rows as the view/scroll area can render on the page ( as determined by height/width of the parent and not the size of the datasource). This is why in Flex you could see a grid render say 20 or more rows filling an entire page with rows, buy see only the 1st 10 populate if the datasource has a length of only 10. For larger datasources that have more entries than there are rows on the view area, the scrollbar is actually paginating the datasources' start point. Every time the start point changes the data throws a change event and every cell re-renders itself based on the new data backing it's cell. The scrollbar is an integral part of the control.

This approach means, then, you can have really heavy/robust cell item renderers ... but you'll never have 1000's of them running, only whats needed to facilitate the view. syncUI() would only happen when the view is created or updated in size. For scalability, this approach would be key.

This does then lead to the next issue of not just databinding of both DTOs/ValueObjects and array and other datasources that controls like yours consume. As Haxe is new to me I am still ignorant of databinding approaches (if any) -- but i mention it for the benefit of your tinkering this weekend as well as others gathering around HaxeUI and wanting to learn it. Perhaps this is the wrong thread. ;-) but clearly with tables -- databinding becomes a leading concern for Flex developers migrating to Haxe. Perhaps a new thread elsewhere is best?

Have a good weekend coding! I'll be checking in!

[ianharrigan]

You are right that it renders each row entirely, and it is something i need to put some serious thought into. Im also planning on giving the listview a spring clean, so maybe it would make sense to tackle that before i look at the tableview again.

One thing about the listview that springs instantly to mind is that they row heights are variable. If you look on the demo is something where you can resize the app (flash, cpp, etc) then if when you resize the app, the list on the left sizes (50%) and so does the word wrapping of one of the list items, and therefore the height of the list item, everything moves accordingly. I dont quite see how that would be doable with static list items.

Another thing is smooth scrolling. If i just had, say 10, visible list items and a datasource of 20 then i think that the list items (say simple text for now), would sort of "jump" instead of nicely scrolling up/down. This is just something im thinking, im sure there is a clever way to achieve that.

Cheers, Ian

[Extra-Extra-Dev]

Devils advocate on "smooth scrolling" comment: Isn't that a UI designer point of view over a UX? The UX would win -- because if the entire site falls apart because 10000 rows bog down the CPU then --- well then ... well that would suck and there was no point of the smooth scrolling. ;-)

But scrolling ( actually, 'pagination' ) in the Flex world is quite quite nice. The rows dont move, the data does. And when you're looking at pages of data, you't care of the pixels of the rows actually move. You want to scroll and sort data.

Now I hear and understand what you are saying about wanting variable-height rows as a feature -- but I think it's feature that has specific if not minimal uses. Perhaps thats a feature saved for Lists, and not Tables? Or, it could be a property of the Table View -- choosing fixed or variable height rows that is. Fixed-height rows would be the default -- as I would assume more people would want a standard grid and a simple table. Leaving the variable-height-cell-type table for people needing it. In my (extensive) experience in the corporate UI world -- the most common if not ONLY use of heavy objects inside a cell were icons, dropdown boxes, and checkboxes -- all of which play nicely visually when scrolling in a fixed height.

Naturally this is your library -- but I would strongly nudge you to think on scalability versus scrolling pixels. Time to bust out some 1000,2000, 5000, and 10000 row tests and see how you feel!

[ianharrigan]

Yeah, dont get me wrong, im in agreement with you, and certainly seeing as the lib is for applications i would expect it to work with that many rows. I think a nice way to implement it (in both lists/tables) would be to have a "virtual = true/false" property, false would mean you would get basically the list as it is now (with the smooth scroll, but in efficient method) and having it off would mean you would get slightly uglier scrolling, but much more scope for loads of items.

Food for though, ill look into it, i think ill start with the listview when i get round to it, im sure anything i implement there will be able to be moved across to the tableview

Cheers, Ian

[Extra-Extra-Dev]

exaaaaaactly -- in regards to it being a property. But "virtual"? How about "virtualScrolling" .. slightly more descriptive.

Careful on your "slightly uglier" comment! Me thinks doth love pixel scrolling too much. ;-) Beauty is in the eye of the beholder.

[ianharrigan]

Haha - this is true! :)

[ianharrigan]

Well, happy to say that virtual scrolls on the scrollview was pretty straight forward (a5fd19dc6bb97b445ae0f6bc359ba70e19eac5f7). It will be needed eventually to make the listview scroll virtually, but it was a pretty worth while enhancement in its own right.

Cheers, Ian

[Extra-Extra-Dev]

OH MY! Will check this out shortly! ;-)

that was fast!

[ianharrigan]

Well, its only the scrollview, didnt get much time over the weekend to get much done on the listview... but think it will work out quite nicely, with the virtualScrolling=true property, did a few tests, etc and i think its more than doable. First i think im going to clean up the ListView (which was long overdue to be fair) and then it should be pretty straightforward to get virtual scrolling to work (i think so anyway)

[ianharrigan]

Ok, so all the bits are in place for virtualisation... :)

• ScrollView can have virtual scrolling
• Components can be cloned (ie, make replicas of themselves)
• ListView now uses itemRenderers

So all thats left now is to actually implement the virtual scrolling on the ListView, which i dont think will be too tough now all the other bits are done.

However, im not going to tackle it just yet, going to try and knock off a few bugs first.

Just thought i would let you know.

Cheers, Ian

[Extra-Extra-Dev]

Great. In hospital maybe next week I can assist?!

-- Martin

On Mar 9, 2014, at 9:01 PM, Ian notifications@github.com wrote:

Ok, so all the bits are in place for virtualisation... :)

ScrollView can have virtual scrolling Components can be cloned (ie, make replicas of themselves) ListView now uses itemRenderers So all thats left now is to actually implement the virtual scrolling on the ListView, which i dont think will be to tough now all the other bits are done.

However, im not going to tackle it just yet, going to try and knock off a few buts first.

Just thought i would let you know.

Cheers, Ian

— Reply to this email directly or view it on GitHub.

[Extra-Extra-Dev]

Hi Ian. I'm home and have updated my workstation to check out what you've done. I see you've improved your website and made some new wonderful-looking demos. Tell me.. do you have the new showcase demo code checked in ( http://haxeui.org/examples/html/showcase/index.html ) It's really impressive!

[Extra-Extra-Dev]

Also curious if you saw the Pixi.js partnership with OpenFL too. I tried to get it work with the upgraded OpenFL 1.3. but doesn't work without adding

I'm just diving in to what Pixi is offering (took me all day to get running again after all the upgrades ).. but seems that this is a great new lib haxeUI needs to know about!

[ianharrigan]

Hello! Hope youre feeling better!

Yeah, i need to spend some time getting it to work with pixi.js... It didnt work out the box for some reason, so ill need to dive in a find out why (previously i added some "#if html5" hacks, so it maybe that these are causing the problems - i hope so! I will be great to remove them). Time is a little short at the moment, but its defo a priority... I was never too bothered about html5, but once it started working im set on keeping it that way!

Also, the showcase case be found here: https://github.com/ianharrigan/haxeui-showcase

Cheers, Ian