gs along on it.
I'm willing to pay to get some help getting things going with this, so if
anyone is interested in TLF tables and wants to make some money doing it,
please drop me a line off-list.
Harbs
er setting the columns directly
>>
>> The second one was table head, table footer and table body elements. The
>> advantage of those would be being able to set all the body cell properties
>> in the table body element. Of course, the same thing could be accomplished
>&
e tag is mainly
for viewing multidimensional data it may lack the considerations that a
Flex application may require. But would you be using TLF tables for
editing? It may be something like the Label and RichEditableText components
where you have one that is for display and another that support
able footer and table body elements. The
>advantage of those would be being able to set all the body cell
>properties in the table body element. Of course, the same thing could be
>accomplished by setting the table properties and overriding them for
>header/footer rows.
>
>>>
element. Of course, the same thing could be accomplished by
setting the table properties and overriding them for header/footer rows.
>> I need some take-aways from this.
>>
>> 1) Do we care to style TLF tables after HTML so the above markup will
>> render? If yes, we pro
On 12/5/13 12:11 AM, "Harbs" wrote:
>Okay. To sum up:
I'm not sure I picked up on whatever point you were trying to make with
the HTML table examples.
>I need some take-aways from this.
>
>1) Do we care to style TLF tables after HTML so the above markup will
>re
January
$100
February
$80
As well as rowspan and colspan.
I don't think cell splits are supported, but they are in DTP applications.
I need some take-aways from this.
1) Do we care to style TLF tables after HTML so the above markup will render?
If ye
On 12/4/13 2:28 PM, "Harbs" wrote:
>It does seem that the table elements were styled after html tables.
>That's where the column groups and table body elements come in:
>http://www.w3schools.com/tags/tag_colgroup.asp
>http://www.w3schools.com/tags/tag_tbody.asp
>
>I think too much effort was ma
It does seem that the table elements were styled after html tables. That's
where the column groups and table body elements come in:
http://www.w3schools.com/tags/tag_colgroup.asp
http://www.w3schools.com/tags/tag_tbody.asp
I think too much effort was made to style TLF after html…
On Dec 5, 2013,
On Dec 4, 2013, at 7:29 PM, Alex Harui wrote:
>
>
> On 12/4/13 6:40 AM, "Harbs" wrote:
>
>> I didn't explain myself very well here.
>>
>> My point is that TLF elements inherit from their parents and we'd get
>> that inheritance from the rows for free if cells are children of rows.
> Yup, so
On 12/4/13 6:40 AM, "Harbs" wrote:
>I didn't explain myself very well here.
>
>My point is that TLF elements inherit from their parents and we'd get
>that inheritance from the rows for free if cells are children of rows.
Yup, so if you set background color on the row it should cover the margins
I didn't explain myself very well here.
My point is that TLF elements inherit from their parents and we'd get that
inheritance from the rows for free if cells are children of rows.
On Dec 4, 2013, at 4:38 PM, Harbs wrote:
> If anything table/row/cell gives more flexibility.
Each composition has a ParcelList which contains one or more
>> parcels.
>>>>>>>> Each ContainerController has one or more parcels in the ParcelList.
>>>>>>>> Generally, there is one parcel per column. (If a ContainerController
>>>>>
l.com]
Envoyé : mercredi 4 décembre 2013 14:33
À : dev@flex.apache.org
Objet : Re: TLF Tables
I would vote for table/cells
I think it more accurately describes a table.
This way you could also more easily set the borders of cells like excell does.
IMO rows and columns don't actually exist, they
e.org
Objet : Re: TLF Tables
I would vote for table/cells
I think it more accurately describes a table.
This way you could also more easily set the borders of cells like excell does.
IMO rows and columns don't actually exist, they are just a coordinate system
to locate a cell.
On Dec 4, 20
ward.
> >>>>>>
> >>>>>> With tables things get a bit more muddled. Each table cell is in
> >>>>>> effect
> >>>>>> a separate composition area. If every composition area gets its own
> >>>>>> pa
rectly, it's supposed to
>>>>>> be
>>>>>> doing this. I think another way to look at it, would be to look at
>>>>>> each
>>>>>> column of each table within a specific Container as a separate
>>>>>> compositio
looking at how
>>>>>parcels
>>>>> work (i.e. vj, etc.), the less this makes sense.
>>>>>
>>>>> So, basically, every cell in the table would be a separate parcel,
>>>>>and
>>>>> these parcels need to be org
gt; interesting.
>>>>
>>>> Here's what I'm not (yet) totally clear on (or even if it works right):
>>>> 1) The logic of placing the table parcels relative to the container
>>>> parcels. The way I see it, the table parcels should be arranged wi
x27;s what I'm not (yet) totally clear on (or even if it works right):
> >> 1) The logic of placing the table parcels relative to the container
> >>parcels. The way I see it, the table parcels should be arranged within
> >>the bounds of the column parcels of the conta
s. This is
>>especially true for tables that might span more than one parent parcel.
>> 3) The placement of the table parcels relative to the container parcels
>>they are contained within. (Should there be a separate ParcelList for
>>table parcels, or should it be part of the m
ithin. (Should there be a separate ParcelList for table
> parcels, or should it be part of the main ParcelList?)
> 4) What I'm not clear on… ;-)
>
> On Nov 28, 2013, at 3:20 PM, Harbs wrote:
>
>> I'm back on this, and starting to make some (slow) progress.
>&g
ress.
>
> I've started a Google Docs document to try to make some order out of the
> chaos that is the current state of TLF Tables. This is just a place where I'm
> jotting down my findings as I go and my thoughts on direction as I work on
> this. I made the document publicl
I'm back on this, and starting to make some (slow) progress.
I've started a Google Docs document to try to make some order out of the chaos
that is the current state of TLF Tables. This is just a place where I'm jotting
down my findings as I go and my thoughts on direction as I
My first tests are not very encouraging…
Trying to compose the table results in this function returning null:
static tlf_internal function beginFactoryCompose():SimpleCompose
{
var rslt:SimpleCompose = _factoryComposer;
is, that would be great!
>
> Either way, I should be giving TLF tables a real workout over the next
> couple of months, so by the time I'm done with it, it should be at the
> point of "officially being supported"… ;-)
>
> Harbs
>
It is very heartening to see TLF ge
Hi Alex,
I realize I'll probably have my work cut out getting everything working as it
should, but it would be helpful at least understanding the design intent.
So, if you could try to jog some memories on this, that would be great!
Either way, I should be giving TLF tables a real workout
Hi Harbs,
I see code for Tables, but I'm not sure it is "officially" there. Or even
complete, or even working at a prototype-level.
So good luck with it. I might be able to ask folks who used to work on it
a few questions, but I'm pretty sure their memories of it are pretty dim
by now.
-Alex
I knew I was going to spend some real time on this one day, and that time is
coming really soon…
Before I dig in too deeply, what's the status on TLF Table support? I know it's
officially there, but I don't see any documentation on it -- not even the
basics on how it's supposed to be used.
I f
develop branch.
>>>
>>> -Fred
>>>
>>> -Message d'origine- From: Harbs
>>> Sent: Sunday, March 17, 2013 4:08 PM
>>> To: dev@flex.apache.org
>>> Subject: Re: TLF Tables
>>>
>>> I'm trying, but I'
flex-sdk, that's the develop branch.
-Fred
-Message d'origine- From: Harbs
Sent: Sunday, March 17, 2013 4:08 PM
To: dev@flex.apache.org
Subject: Re: TLF Tables
I'm trying, but I'm having a heck of a time wrapping my head around git? :-(
TLF has the following bran
> -Message d'origine- From: Harbs
> Sent: Sunday, March 17, 2013 4:08 PM
> To: dev@flex.apache.org
> Subject: Re: TLF Tables
>
> I'm trying, but I'm having a heck of a time wrapping my head around git… :-(
>
>
> TLF has the following branches: 1
Hi Harbs,
You should consider to checkout only the master branch to have the last code
on this repo, for the flex-sdk, that's the develop branch.
-Fred
-Message d'origine-
From: Harbs
Sent: Sunday, March 17, 2013 4:08 PM
To: dev@flex.apache.org
Subject: Re: TLF Tables
I'm trying, but I'm having a heck of a time wrapping my head around git… :-(
TLF has the following branches: 1, 1.1, 2, 2.1, 3.0, HEAD and Master.
Where would I look for the code? (not that I've figured out the difference
between Checkout, Fetch and Pull yet…)
Harbs
On Mar 17, 2013, at 4:57
I'd scan the source code for "Table" and see what you find.
On 3/17/13 6:22 AM, "Harbs" wrote:
> There were a couple of bugs in the Adobe JIRA on table support in TLF [1] [2]
> These were transferred over to Apache JIRA here. [3] [4]
>
> There have been inferences that it was supposed to be av
There were a couple of bugs in the Adobe JIRA on table support in TLF [1] [2]
These were transferred over to Apache JIRA here. [3] [4]
There have been inferences that it was supposed to be available in TLF 3, but
to the best of my knowledge that did not happen.
What is the status of table suppo
36 matches
Mail list logo
