Bah! I’ve been relying on replaceChildren(), findChild(), etc.for TableCellElements.
None of that will work if I change TableElement to a leaf… I could really use multiple inheritance. Why was TLF designed that elements are either leaf elements of group elements? Couldn’t elements conceivably be both / either? On Jun 9, 2014, at 10:18 PM, Harbs <harbs.li...@gmail.com> wrote: > OK. > > I’ll see how it goes... > > On Jun 9, 2014, at 9:31 PM, Alex Harui <aha...@adobe.com> wrote: > >> OK, I guess TLF doesn't really have block elements. I was just wondering >> if there would be some problem further down the line. Folks seem to want >> to have TLF elements work like HTML elements. >> >> I was pondering if you next had to support DIV and if block elements >> should first be introduced to TLF. So those are some concerns that popped >> into my head, but no real objections at this point. >> >> Good luck, >> -Alex >> >> On 6/9/14 11:21 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> That’s pretty close to what I already did. Table composition is all >>> working very well as each table cell acting as a separate TextFlow and >>> container. Except extending InlineGraphicElement does not make sense. >>> There’s a lot of code in there dealing with loading assets which is not >>> applicable to tables. >>> >>> I’d just subclass FlowLeafElement (which is what InlineGraphicElement >>> does) instead of subclassing FlowGroupElement as tables currently do. >>> >>> If I had to pick between block or inline for tables, I think I’d pick >>> inline… >>> >>> On Jun 9, 2014, at 9:05 PM, Alex Harui <aha...@adobe.com> wrote: >>> >>>> I'm not an HTML expert, but they seem to divide up their elements >>>> between >>>> those that default to "inline" and those that default to "block". I >>>> think >>>> in TLF, SpanElement and InlineGraphicElement are inline and >>>> ParagraphElement is "block". I haven't really thought through this, but >>>> one possible strategy to make Table extend InlineGraphicElement to >>>> reserve >>>> space and then then make each cell its own TLF container in that space? >>>> Is that sort of what you are trying to do? >>>> >>>> -Alex >>>> >>>> On 6/9/14 10:28 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>>> >>>>> I have not yet implemented arrow navigation (beyond what was there >>>>> originally), but here’s my plan: >>>>> >>>>> * When text outside the table is selected, arrow navigation would treat >>>>> the entire table like a single atom (i.e. if the cursor is right >>>>> before, >>>>> a right arrow will move the cursor beyond the table). >>>>> * If text inside a cell is selected, arrow navigation will work within >>>>> the cell confines (as a separate TextFlow) >>>>> * If a cell is selected, arrow navigation will select the next previous >>>>> cell in the row/column. >>>>> >>>>> #1 and #2 should be working now out of the box. #3 will take a bit of >>>>> work getting it to work. >>>>> >>>>> In HTML, tables are general layout elements similar to divs. I’m >>>>> treating >>>>> tables much differently. (Each cell is a separate TextFlow.) Trying to >>>>> handle tables purely inline had too many challenges for me to >>>>> stomach... >>>>> Just looking at the spaghetti that was composition and selections made >>>>> me >>>>> dizzy... >>>>> >>>>> Treating tables as block elements, requires handling the table content >>>>> as >>>>> leaf elements. This make composition and selections (especially things >>>>> like column selections) very challenging. >>>>> >>>>> On Jun 9, 2014, at 7:20 PM, Alex Harui <aha...@adobe.com> wrote: >>>>> >>>>>> What is the leftArrow/rightArrow navigation model when Tables are >>>>>> involved? >>>>>> >>>>>> Also, in HTML, isn't a Table a block-level element? Are there other >>>>>> reasons for making it a leaf? Shouldn't Table be more like >>>>>> ParagraphElement? >>>>>> >>>>>> -Alex >>>>>> >>>>>> On 6/8/14 10:48 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>>>>> >>>>>>> My real concern is the fact that findLeaf() is used in so many >>>>>>> places. >>>>>>> It >>>>>>> makes the assumption that you can find a leaf by index anywhere in a >>>>>>> text >>>>>>> flow. That assumption falls apart with tables. I make a clear >>>>>>> separation >>>>>>> between tables and their contents. As far as the text flow is >>>>>>> concerned, >>>>>>> the table has a single index (and can only be selected as a whole >>>>>>> when >>>>>>> selected with surrounding text). >>>>>>> >>>>>>> So, unless I go through every place findLeaf() is used in TLF and >>>>>>> make >>>>>>> special cases for tables, the only way I can see of handling it is by >>>>>>> making a table a leaf. Even if I fix all the findLeaf() calls in the >>>>>>> framework, I’d still be causing client code to fall apart when it >>>>>>> comes >>>>>>> to tables. >>>>>>> >>>>>>> Although tables have cell children, they are not index tracked within >>>>>>> the >>>>>>> text flow as other children are. I could override the text property >>>>>>> to >>>>>>> return all text contents of all cells in the table. That actually >>>>>>> makes >>>>>>> kind of sense. >>>>>>> >>>>>>> On Jun 9, 2014, at 6:59 AM, Alex Harui <aha...@adobe.com> wrote: >>>>>>> >>>>>>>> Hmm. The doc says that FlowLeafElement doesn't have any children. >>>>>>>> But >>>>>>>> Tables can certainly contain other tables, right? And aren't the >>>>>>>> headers/rows/cells considered children? >>>>>>>> >>>>>>>> FlowLeafElement also has a text property. Are you going to be >>>>>>>> overriding >>>>>>>> that? >>>>>>>> >>>>>>>> Is it just too hard to make a TableElement extend FlowElement and in >>>>>>>> other >>>>>>>> ways be treated as an InlineGraphicElement? >>>>>>>> >>>>>>>> -Alex >>>>>>>> >>>>>>>> On 6/8/14 12:46 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Please see this issue. I¹m sure there are plenty of related bugs. >>>>>>>>> >>>>>>>>> https://github.com/Harbs/TLF-Table-Work/issues/28 >>>>>>>>> >>>>>>>>> I¹m thinking of changing the base-class of TableElement to change >>>>>>>>> it >>>>>>>>> to a >>>>>>>>> leaf element rather than a group element. I don¹t see any reason >>>>>>>>> off-hand >>>>>>>>> not to do that, but I very likely might be missing something. >>>>>>>>> >>>>>>>>> Reason why I think it makes sense: >>>>>>>>> >>>>>>>>> Basically, I¹m treating a table as an inline object. The contents >>>>>>>>> of >>>>>>>>> a >>>>>>>>> table are laid out in a grid, but largely independent from the main >>>>>>>>> text >>>>>>>>> composition. It¹s really not much more than a really fancy inline >>>>>>>>> object >>>>>>>>> (or one that can span across multiple containers). >>>>>>>>> >>>>>>>>> If anyone can think of a good reason why it¹s a bad idea, I¹d >>>>>>>>> really >>>>>>>>> like >>>>>>>>> to hearŠ >>>>>>>>> >>>>>>>>> Harbs >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
