Fx Prefix Resolution

[Ben Stucki]

This thread is intended to bring the Flex SDK Community Committee to a consensus concerning proposed namespace solutions, with the intent to publicly back that decision in mass. For posterity please make sure you review the Adobe forum thread on the subject at http://www.adobeforums.com/webx?128@@.59b7cdf0 before commenting.

There are a lot of issues flying back and forth around this, but I'm hoping we can keep the scope of this discussion focused on introducing points you feel we need to back as a group and eliminating points that you aren't willing to back. If we can nail it down like this first to keep the noise low, then we'll still be able to make it a little less formal later and see if we all back any one proposal. I'll get us started with a few line items that I think we should back.

1. Namespaces MUST be used to differentiate components that otherwise conflict. Class prefixing MUST NOT be used for this distinction.

2. CSS namespace support MAY be introduced to resolve conflicts but MUST conform to the CSS recommendation at http://www.w3.org/TR/2008/CR-css3-namespace-20080523/ .

The MUST/MAY/SHOULD language just keeps things clear for me, but it's not required if you want to propose something. These items are basically just backing Matt's proposal and example code, which I think is exactly what I wanted. Other items that are up for recommendation might be merging/separating the language and both component namespaces or ideas you might have for keeping MXML simple for new users (while keeping us happy). If you're not willing to back an item being recommended speak up! :-)

[Ben Clinkinbeard]

Great post Ben. I think the MUST/MAY/SHOULD is a great way to informally measure agreement within this group. I am including/proposing a convention below of using bolded numbers with hash marks to denote specific items for discussion. I think these conventions used together will make quantifying the group's collective opinions that much easier.


#1 - Namespaces MUST be used to differentiate components that otherwise conflict. Class prefixing MUST NOT be used for this distinction.

Agreed. This point may represent a rare instance where disagreement is grounds for membership revocation. :)

#2 - CSS namespace support MAY be introduced to resolve conflicts but MUST conform to the CSS recommendation at http://www.w3.org/TR/2008/CR-css3-namespace-20080523/ .

That spec looks pretty solid and I would love for Adobe to implement it but I'd be inclined to say SHOULD where you have MUST. I could support MUST if the group prefers it.


New proposals:

#3 - ASDoc MAY use icons to differentiate architectures as it currently does for AIR properties.

#4 - Tooling (FlexBuilder) SHOULD use compiler settings/target SDK to determine ordering in code completion lists and MAY use icons to further differentiate between architectures.


Ben

[Tom Chiverton]

(MUST/SHOULD is familiar from RFC, lets keep it)

#5 Tooling SHOULD offer both mx:Button and fx:Button when the user
types 'But'. Tooling MAY choose to use one prefix as the default, in
which case it SHOULD indicate that the un-prefixed class is mx or fx

#6 Tooling SHOULD have a way to define the default mx/fx where class
conflicts occur.

#7 It MUST be possible to use styleName parameter to apply styles to
instances of either mx or fx Button

#8 Search results (i.e. 'community search') SHOULD prefer new Flex 4
components. LiveDocs for Flex 4 MUST prefer Flex 4 components but
SHOULD link to Flex 3 classes too.

--
Tom

[Ryan Campbell]

I don't have any new numbered points, but have a bit of input to back up the already listed items in this thread.

To me, the CSS Namespace support is an important one because I believe they should always learn towards an already open standard to solve an issue rather than coming up with their own quick fix.

Also, if they see CSS selector conflicts as such a major issue then they, as the owners of the core framework/platform, have the responsibility to fix this issue as a whole and not just for themselves. If they simply prefix their components with Fx and call it a day, where does that leave all third party component developers? I know I'm not interested in prefixing all OpenFlux components with Flux.

--

Ryan

[Ben Clinkinbeard]

I think #5 and #6 are already covered by #3 and #4. If the wording of 3 and 4 needs to be refined let me know.

#7 - I think that is a given so I would suggest we not include it in our list. The more compact our argument the better imo.

I propose the following version of #8

#8 - LiveDocs MUST prefer the component version that matches the language reference version where the search occurred. Docs for overlapping classes SHOULD include links to alternate versions.

Ben

[Tom Ortega]

I'm down with #3, but say let's be bolder with:

#3 - ASDoc SHOULD use icons to differentiate architectures as it
currently does for AIR properties. In addition, Flex 4 LiveDocs
Language Reference SHOULD (by default) hide all Flex 3 components when
there is a Flex 4 replacement.

The already started one paradigm with the icons, so they should stick
with it. The latter part will set the stage for slowing phasing out
the old with the new.

A question i have in regards to that last bit also is will every
component/class be ported eventually? Or will we always have this
mixed types? (sorry if that's obvious, but i haven't really read up
on that much)

I also suggest this change to #8:

#8 - LiveDocs MUST prefer the component version that matches the

language reference version where the search occurred AND MUST never
return a result for a version that's higher. Docs for overlapping
classes SHOULD include links to *earlier* versions.

I don't think Flex 3 classes should link to Flex 4, but I do think
they can go the other way. The problem will be the whole community
results, blog posts, etc. There's no way to know which posts refer to
which version.

Tom Ortega
360Conferences, Inc.
cell: 951.212.9686 | twitter/skype: lordbron
lordbron.wordpress.com | www.OurStartupStory.com |
www.360conferences.com | www.360flex.com | www.360iDev.com

[Ben Clinkinbeard]

Aren't we just talking about LiveDocs searches? How do blog posts get into the results? I have a feeling I am missing something here.

[Tom Ortega]

My bad:

I forgot they implemented the " Show only content from Adobe" feature.
It did return community help when community help first launched.

Tom Ortega
360Conferences, Inc.
cell: 951.212.9686 | twitter/skype: lordbron
lordbron.wordpress.com | www.OurStartupStory.com |
www.360conferences.com | www.360flex.com | www.360iDev.com

On Sat, Feb 7, 2009 at 7:50 AM, Ben Clinkinbeard

[Brian Holmes]

I back #1, #2, #3, #4, and #8.

For number #2 I'd be inclined to say SHOULD instead of MUST as well.
Or perhaps SHOULD STRIVE. It'd be great if they did support it and I'd
agree with Ryan that when in doubt they should lean toward an existing
standard. For the sake of moving forward, I'd support MUST if it's
preferred.

Numbers #5, #6 AND #7 look covered by the preceding ones and I'm
pretty happy with the texts.

One other thing that kind of sticks out in my mind in relation to any
question like those in this list or the adobe forums and was something
I thought was a given till I read Matt C's list on the adobe forums is
no matter the topic concerning this whether it's css, namespaces,
component lists, auto completion, documentation, etc.. is that they
all SHOULD default or PREFER to the latest build/ version ( as in Flex
4 over Flex 3 ) unless I as the developer specifically indicate
otherwise. With that in mind it really only leaves me with #1 and #2.
and i included #2 because it does seem a big issue for Adobe, even if
i see it as a side issue.

Let the namespace do it's job!

[Tom Chiverton]

2009/2/7 Ryan Campbell <ry...@safaricreative.com>:

> To me, the CSS Namespace support is an important one because I believe they
> should always learn towards an already open standard to solve an issue
> rather than coming up with their own quick fix.

Indeed. But I think it should be SHOULD, because if the choice is 'In
order to support CSS correctly in the time frame, we have to keep
FxButton' Adobe should be able to break with the CSS spec.

--
Tom

[Doug McCune]

Hey, why not throw each individual point up onto user voice, which would let us modify each one individually, have threaded comments on each particular point instead of the entire list, and let us vote each one up or down?

[Ben Clinkinbeard]

I started to do that and now I'm wondering if that's the best place. There already seem to be some anonymous comments and votes there and I think we need to come to a consensus pretty quickly on these things so we can chime in on the forums. Should we separate these points into threads here or on uservoice?

[Tom Chiverton]

2009/2/7 Ben Clinkinbeard <ben.clin...@gmail.com>:

> I started to do that and now I'm wondering if that's the best place. There
> already seem to be some anonymous comments and votes there and I think we
> need to come to a consensus pretty quickly on these things so we can chime
> in on the forums. Should we separate these points into threads here or on
> uservoice?

I don't think there is time for a full public vote, unfortunately. The
discussion will move on without this group...

--
Tom

[Brian Holmes]

I agree with Tom.. unfortunately as well. I say we create a Page for
our Fx resolutions. Put the ones we've all agreed in there and get it
over to Adobe. by posting it on the current Adobe Forum thread.

[Doug McCune]

My only point was that adding items to an email thread doesn't seem like good method. That means we have to keep referring to items in previous emails (which may have undergone multiple revisions) and we'll end up with a huge game of copy/paste telephone where nobody knows what version of the commandments your're referring to. Having each listed on a single Page is fine with me, I just don't want to have to say things like "I agree with Ben's updated version of item #3 as long as it doesn't include Tom's alteration" or whatever.

And I also certainly wasn't saying use uservoice for widespread community voting, just for our own voting. I just want to be able to discuss single items without losing track of what we're talking about.

Doug

[Ben Stucki]

I'm okay with using SHOULD for #2 if we have to, but I just wanted to point out that this item as a whole is qualified with MAY for exactly this reason. It's saying that if they do decide to implement namespaces in CSS they have to do it by the recommendation, but if they don't do CSS namespaces at all that's okay too. The main thing I'm hoping to avoid is Adobe inventing a new CSS syntax for something that already has a recommendation. I don't think they would anyways, but of course I didn't think they would use Class prefixing either. :-)

[Ben Clinkinbeard]

Agreed as well but I see Doug's point about keeping things clear. I am going offline for a while so if somebody else wants to break the items into separate threads go for it. If that hasn't happened by this evening I can do it. Maybe we create private surveys using Google docs for each one? For ones where verbiage is being debated we could have alternate versions (2a and 2b) and instruct people to choose the one they prefer.

Ben

[Brian Holmes]

I pulled all the items as originally stated out of this thread and put
them on a page found here

http://groups.google.com/group/flex-sdk-community-committee/web/fx-prefix-resolution

Perhaps we should set a deadline to argue our points on them? Say
sometime tonight? 6 EST? Then they're going to the Adobe forums? I
don't think they need to be perfectly worded. It's much more
imperative we participate in the bigger conversation on the Adobe
forums to be relative.

[Brian Holmes]

If anybody's unhappy with the wording of one of the items, create a
new thread specific for that item. Lack of conversation on an item
will assume everybody's in agreement over that item.

[Ben Stucki]

I'm a little scared of breaking it into threads, but of course this ones got more noise already than I intended. I think one thing that I wasn't counting on is the scope of things we're talking about. Are decisions on how it's represented in the docs really something we need to weigh in on? I think as long as it's in there I'm happy. Are some of these tooling decisions going to be deal breakers for the people recommending it? They may be and I'm okay with adding these items if someone feels they're really important, but they aren't really deal breakers for me. I think we should be very deliberate and concise in what are points are to be sure each one carries weight from us.

[Tom Ortega]

Yeah as for the livedocs, the documetation team is pretty open to
those that care. So we can approach them separately if need be.

Thanks,

Tom Ortega
360Conferences, Inc.
cell: 951.212.9686 | twitter/skype: lordbron
lordbron.wordpress.com | www.OurStartupStory.com |
www.360conferences.com | www.360flex.com | www.360iDev.com

[Ben Clinkinbeard]

I completely agree 1 and 2 are the only vital items. I only added to
the list and think we should include the others bc Adobe seems to
think they're important. I don't want them to have an easy "what about
x" way out.

[Tom Chiverton]

2009/2/7 Ben Clinkinbeard <ben.clin...@gmail.com>:

> the list and think we should include the others bc Adobe seems to
> think they're important. I don't want them to have an easy "what about
> x" way out.

Exactly. They've told us what they see as the obstacles to not having
a hacky prefix. We have to address their concerns.

--
Tom

[Ben Stucki]

Yeah, I definitely see that need too. Maybe we should separate them out though. Put the must haves on top, then viable solutions to issues Adobe raises in a second section.

[Ben Clinkinbeard]

I've updated the page and split the items into primary and secondary groupings. http://groups.google.com/group/flex-sdk-community-committee/web/fx-prefix-resolution

I think we should get this page and the mission statement nailed down by Monday so we can post to the Adobe forums. Silence will be interpreted as acceptance.

[Ben Clinkinbeard]

Going once, going twice... unless I hear otherwise by end of day
Tuesday I will consider the current version of the page to be approved
and ready for publish.

Speaking of, suggestions on how to present it? Do I just post it from
my account and sign it from the committee? Do we create a forums
account for the committee? Do we list members' names in the post?
Suggestions appreciated.



On Feb 7, 8:45 pm, Ben Clinkinbeard <ben.clinkinbe...@gmail.com>
wrote:

> I've updated the page and split the items into primary and secondary

> groupings.http://groups.google.com/group/flex-sdk-community-committee/web/fx-pr...

>
> I think we should get this page and the mission statement nailed down by
> Monday so we can post to the Adobe forums. Silence will be interpreted as
> acceptance.
>

> On Sat, Feb 7, 2009 at 4:27 PM, Ben Stucki <benstu...@gmail.com> wrote:
> > Yeah, I definitely see that need too. Maybe we should separate them out
> > though. Put the must haves on top, then viable solutions to issues Adobe
> > raises in a second section.
>
> > On Sat, Feb 7, 2009 at 3:20 PM, Ben Clinkinbeard <
> > ben.clinkinbe...@gmail.com> wrote:
>
> >> I completely agree 1 and 2 are the only vital items. I only added to
> >> the list and think we should include the others bc Adobe seems to
> >> think they're important. I don't want them to have an easy "what about
> >> x" way out.
>

> >> On 2/7/09, Ben Stucki <benstu...@gmail.com> wrote:
> >> > I'm a little scared of breaking it into threads, but of course this ones
> >> got
> >> > more noise already than I intended. I think one thing that I wasn't
> >> counting
> >> > on is the scope of things we're talking about. Are decisions on how it's
> >> > represented in the docs really something we need to weigh in on? I think
> >> as
> >> > long as it's in there I'm happy. Are some of these tooling decisions
> >> going
> >> > to be deal breakers for the people recommending it? They may be and I'm
> >> okay
> >> > with adding these items if someone feels they're really important, but
> >> they
> >> > aren't really deal breakers for me. I think we should be very deliberate
> >> and
> >> > concise in what are points are to be sure each one carries weight from
> >> us.
>
> >> > On Sat, Feb 7, 2009 at 2:09 PM, Ben Clinkinbeard <

> >> ben.clinkinbe...@gmail.com

> >> >> wrote:
>
> >> >> Agreed as well but I see Doug's point about keeping things clear. I am
> >> >> going offline for a while so if somebody else wants to break the items
> >> >> into
> >> >> separate threads go for it. If that hasn't happened by this evening I
> >> can
> >> >> do
> >> >> it. Maybe we create private surveys using Google docs for each one? For
> >> >> ones
> >> >> where verbiage is being debated we could have alternate versions (2a
> >> and
> >> >> 2b)
> >> >> and instruct people to choose the one they prefer.
>
> >> >> Ben
>
> >> >> On Sat, Feb 7, 2009 at 3:00 PM, Brian Holmes

> >> >> <brian.josep...@gmail.com>wrote:

[Tink]

Sorry I'm sp late in on this stuff

I think the proposals sound good, but here's a couple of comments

--------------------------------------------------------------------

"*#4 - *Tooling (FlexBuilder) SHOULD use compiler settings/target SDK

to
determine ordering in code completion lists and MAY use icons to
further
differentiate between architectures. "

The above suggestion means that the order could change in diff
projects. I think I'd prefer it to stay in the same order at all
times.

--------------------------------------------------------------------

"#5 Tooling SHOULD offer both mx:Button and fx:Button when the user
types 'But'. Tooling MAY choose to use one prefix as the default, in
which case it SHOULD indicate that the un-prefixed class is mx or fx "

I know that #5 is addressed elsewhere, but I didn't really understand.
The suggestion is that after typing 'But' FB would be able to auto-
complete. At the moment this isn't possible as FB still needs to list
all 8 classes that begin with 'But'. I guess I just don't understand
the term 'default' being used here.

--------------------------------------------------------------------

Tink

[Tom Chiverton]

2009/2/10 Tink <sdo...@gmail.com>:

> The above suggestion means that the order could change in diff
> projects. I think I'd prefer it to stay in the same order at all
> times.

Others wouldn't however (in legacy Flex 3 projects, for instance). It
should be a default that can be changed globally or per-project.

> "#5 Tooling SHOULD offer both mx:Button and fx:Button when the user
> types 'But'. Tooling MAY choose to use one prefix as the default, in
> which case it SHOULD indicate that the un-prefixed class is mx or fx "

> all 8 classes that begin with 'But'. I guess I just don't understand
> the term 'default' being used here.

If I type 'But' and press ctrl-space, the top of the list should be:
mx:Button
fx:Button

--
Tom

[Tom Chiverton]

2009/2/10 Ben Clinkinbeard <ben.clin...@gmail.com>:

> Speaking of, suggestions on how to present it? Do I just post it from
> my account and sign it from the committee? Do we create a forums
> account for the committee? Do we list members' names in the post?
> Suggestions appreciated.

We also need to put the 'our mission' on the googles group page and
start blogging our existance once that is done.

Make one post to the forum thread 'from the Committee', with all our
names at the bottom.

--
Tom

[Tom Chiverton]

2009/2/10 Ben Clinkinbeard <ben.clin...@gmail.com>:

> Going once, going twice... unless I hear otherwise by end of day
> Tuesday I will consider the current version of the page to be approved
> and ready for publish.

http://groups.google.com/group/flex-sdk-community-committee/web/fx-prefix-resolution
still says "MUST conform to the CSS recommendation" and I don't like
the idea of backing the impl. into a corner like that. I'd rather they
dropped CSS spec. compliance than kept fxButton.

--
Tom

[Tink]

It's difficult to have an opinion without having used it for a few
days, but my initial feelings are

Others wouldn't however (in legacy Flex 3 projects, for instance). It
should be a default that can be changed globally or per-project.

For me consistency is key. I want it to remain the same always.

If I type 'But' and press ctrl-space, the top of the list should be:
mx:Button
fx:Button

I would prefer this list to always remain consistent, and therefore
alphabetical. I currently find it weird that mx classes get listed
above my own namespaces such at 'controls' i.e....

I type '<But', and get the following list

mx:Button
mx:ButtonBar
controls:Button

IMO controls:Button should be listed at the top. Listing things
alphabetical enables constancy.

[Tom Chiverton]

2009/2/10 Tink <sdo...@gmail.com>:

> I would prefer this list to always remain consistent, and therefore
> alphabetical. I currently find it weird that mx classes get listed
> above my own namespaces such at 'controls' i.e....

Sounds like some more options in Builder would sort us both out :-)

--
Tom

[Tink]

I guess, but there still has to be a default.