Here’s a wacky idea: I can leave tables as group elements for managing table cell elements and formatting inheritance purposes. I can introduce a TableLeafElement class whose sole purpose is describing the contents of the table and satisfying getLeaf() calls. I’d override getLeaf() for TableElement to return TableLeafElement.
On Jun 9, 2014, at 10:59 PM, Harbs <harbs.li...@gmail.com> wrote: > 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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >