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
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Reply via email to