You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2017/06/06 05:58:50 UTC
Finding tools in the toolbox
One of the most difficult part of dealing with FlexJS and beads is knowing what beads are available and what beads are interchangeable.
I think we need a system to programmatically be able to look up bead and strand relationships. This could be used by documentation as well as tooling to give hints as to what beads to use.
I think there’s been some discussion already on this, but I’m kind of fuzzy and it probably needs some more.
Harbs
Re: Finding tools in the toolbox
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'm not sure what is possible in Flash Builder. I honestly don't use
code-hinting in FB because I know the APIs pretty well. If FB with the
regular Flex SDK can offer allowed values for properties, then it should
be possible to offer allowed values for the bead property, although I
think that is done via Metadata and thus won't offer some third-party
offering we didn't know about at framework compile time.
Similarly, if FB already offers refactor via replace, it also probably
relies Metadata and using the same metadata tags on framework classes
should work.
I am hopeful that Josh's VSCode support and other folks who are supporting
FlexJS IDEs will offer more dynamic and powerful support for this kind of
code-hinting.
In FB, if you package DITA files in the SWCs, FB will offer ASDoc in its
code hinting. I have not had time to see how good the DITA output is that
Christofer Dutz worked on and try to package it in the SWCs. Maybe a
volunteer can help with that.
HTH,
-Alex
On 6/6/17, 11:36 AM, "Harbs" <ha...@gmail.com> wrote:
>Here’s what I’m after:
>1. In mxml, I’d like to markup <beads> and then be given a list of valid
>beads for the current component. What’s the easiest way for tooling to
>get such a list?
>2. With a bead selected, I’d like tooling to allow refactor and give a
>list of beads which can replace the current one with alternate
>functionality. (i.e. different layout, different scrolling behavior,
>different skinning behavior, etc.) It should only present the ones which
>are deemed a “replacement”. Extra credit for docs which describe what the
>bead does.
>
>Harbs
>
>> On Jun 6, 2017, at 8:20 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> You are welcome to add a new tag. Could be something like
>>
>> @workswith classOrInterface
>>
>> Or maybe @knownstrands.
>>
>> I'm not sure what you visualize for "display hierarchy" and "code
>> hinting". Fundamentally, we have raw data in .json files and you can
>> write code to process and visualize that data.
>>
>> I would prefer that folks hold off on adding new tags until after we get
>> the release out and merge the release branch back to develop.
>>Otherwise,
>> I think it will increase the likelihood of merge conflicts.
>>
>> -Alex
>>
>> On 6/6/17, 10:01 AM, "Harbs" <harbs.lists@gmail.com
>><ma...@gmail.com>> wrote:
>>
>>> It seems like there should be a mechanism to add arbitrary tags that
>>> include references to acceptable components. Maybe use interfaces to
>>> indicate swap-ability?
>>>
>>> What format would be best for tooling to display hierarchy and code
>>> hinting? Should there be a manifest file, or is the ASDoc enough for
>>>that?
>>>
>>>> On Jun 6, 2017, at 7:51 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>wrote:
>>>>
>>>> View beads have @viewbead ASDoc tag
>>>> Top-level components have @toplevel ASDoc tag.
>>>>
>>>> All tags are output to tags.json and the ASDoc example could implement
>>>> any
>>>> sort of filtering based on those tags. New tags I think can be added
>>>>by
>>>> just adding them to the ASDoc and maybe telling the compiler to hide
>>>>it
>>>> from Google Closure.
>>>>
>>>> That's why I see the need for something that is more of an
>>>>"application"
>>>> for our documentation. The app can compute relationships based on
>>>>data.
>>>> Volunteers are encouraged to improve this capability for our ASDoc.
>>>>We
>>>> also probably need to solve search engine interfaces for the app as
>>>> well.
>>>>
>>>> BTW, I got the ASDoc in the CI server to work again. Here are links
>>>>to
>>>> the SWF version [1] and JS version[2].
>>>>
>>>> -Alex
>>>>
>>>> [1]
>>>>
>>>>
>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachef
>>>>le
>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache
>>>>fle>
>>>> xbuild.cloudapp.net
>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fxbuild
>>>>.cloudapp.net%2F&data=02%7C01%7C%7C26dd811431454add37c708d4ad0b0973%7Cf
>>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636323710295199629&sdata=Jg0e
>>>>SxIfoSrrLCtD0O3J9xcfFcse5anmvdLUd7xFIMo%3D&reserved=0>%3A8080%2Fjob%2FF
>>>>lexJS_ASDoc_Example%2FlastSucce&data=
>>>>
>>>>02%7C01%7C%7C46e612dfe85445e0789308d4acfda6ad%7Cfa7b1b5a7b34438794aed2c
>>>>17
>>>>
>>>>8decee1%7C0%7C0%7C636323652817901308&sdata=s8fFgxBrse1R0EYwAuEQmDD9QSQF
>>>>kw
>>>> lDDmQFoc9dNWU%3D&reserved=0
>>>> ssfulBuild/artifact/examples/flexjs/ASDoc/bin-debug/ASDoc.html
>>>>
>>>> [2]
>>>>
>>>>
>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachef
>>>>le
>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache
>>>>fle>
>>>> xbuild.cloudapp.net
>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fxbuild
>>>>.cloudapp.net%2F&data=02%7C01%7C%7C26dd811431454add37c708d4ad0b0973%7Cf
>>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636323710295199629&sdata=Jg0e
>>>>SxIfoSrrLCtD0O3J9xcfFcse5anmvdLUd7xFIMo%3D&reserved=0>%3A8080%2Fjob%2FF
>>>>lexJS_ASDoc_Example%2FlastSucce&data=
>>>>
>>>>02%7C01%7C%7C46e612dfe85445e0789308d4acfda6ad%7Cfa7b1b5a7b34438794aed2c
>>>>17
>>>>
>>>>8decee1%7C0%7C0%7C636323652817901308&sdata=s8fFgxBrse1R0EYwAuEQmDD9QSQF
>>>>kw
>>>> lDDmQFoc9dNWU%3D&reserved=0
>>>> ssfulBuild/artifact/examples/flexjs/ASDoc/bin/js-debug/index.html
>>>>
>>>> On 6/6/17, 8:46 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> What do the annotations look like?
>>>>>
>>>>> Maybe there should be some kind of manifest that documents beads and
>>>>> their relationships?
>>>>>
>>>>>
>>>>>> On Jun 6, 2017, at 5:46 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>> wrote:
>>>>>>
>>>>>> Definitely needs more.
>>>>>>
>>>>>> In the ASDoc example, there is a checkbox to see just view beads. I
>>>>>> have
>>>>>> added ASDoc annotations to the view beads so they show up when that
>>>>>> filter
>>>>>> is on. I'm sure view beads may have been added since I first did
>>>>>> that,
>>>>>> and maybe the annotation accidentally got copied into new beads that
>>>>>> aren't view beads, but that's my idea for how to find tools in the
>>>>>> toolbox.
>>>>>>
>>>>>> If folks like it, please add more annotations and propose and
>>>>>> implement
>>>>>> how to generalize the filtering so it isn't 40 checkboxes some day.
>>>>>>
>>>>>> BTW, the ASDoc example on the CI server is broken. That'll be my
>>>>>> stop-ship release bug for today. Until then, you can build the
>>>>>> example
>>>>>> locally and see how the checkbox works.
>>>>>>
>>>>>> Thanks,
>>>>>> -Alex
>>>>>>
>>>>>> On 6/5/17, 10:58 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>
>>>>>>> One of the most difficult part of dealing with FlexJS and beads is
>>>>>>> knowing what beads are available and what beads are
>>>>>>>interchangeable.
>>>>>>>
>>>>>>> I think we need a system to programmatically be able to look up
>>>>>>>bead
>>>>>>> and
>>>>>>> strand relationships. This could be used by documentation as well
>>>>>>>as
>>>>>>> tooling to give hints as to what beads to use.
>>>>>>>
>>>>>>> I think there’s been some discussion already on this, but I’m kind
>>>>>>>of
>>>>>>> fuzzy and it probably needs some more.
>>>>>>>
>>>>>>> Harbs
>
Re: Finding tools in the toolbox
Posted by Harbs <ha...@gmail.com>.
Here’s what I’m after:
1. In mxml, I’d like to markup <beads> and then be given a list of valid beads for the current component. What’s the easiest way for tooling to get such a list?
2. With a bead selected, I’d like tooling to allow refactor and give a list of beads which can replace the current one with alternate functionality. (i.e. different layout, different scrolling behavior, different skinning behavior, etc.) It should only present the ones which are deemed a “replacement”. Extra credit for docs which describe what the bead does.
Harbs
> On Jun 6, 2017, at 8:20 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> You are welcome to add a new tag. Could be something like
>
> @workswith classOrInterface
>
> Or maybe @knownstrands.
>
> I'm not sure what you visualize for "display hierarchy" and "code
> hinting". Fundamentally, we have raw data in .json files and you can
> write code to process and visualize that data.
>
> I would prefer that folks hold off on adding new tags until after we get
> the release out and merge the release branch back to develop. Otherwise,
> I think it will increase the likelihood of merge conflicts.
>
> -Alex
>
> On 6/6/17, 10:01 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
>> It seems like there should be a mechanism to add arbitrary tags that
>> include references to acceptable components. Maybe use interfaces to
>> indicate swap-ability?
>>
>> What format would be best for tooling to display hierarchy and code
>> hinting? Should there be a manifest file, or is the ASDoc enough for that?
>>
>>> On Jun 6, 2017, at 7:51 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> View beads have @viewbead ASDoc tag
>>> Top-level components have @toplevel ASDoc tag.
>>>
>>> All tags are output to tags.json and the ASDoc example could implement
>>> any
>>> sort of filtering based on those tags. New tags I think can be added by
>>> just adding them to the ASDoc and maybe telling the compiler to hide it
>>> from Google Closure.
>>>
>>> That's why I see the need for something that is more of an "application"
>>> for our documentation. The app can compute relationships based on data.
>>> Volunteers are encouraged to improve this capability for our ASDoc. We
>>> also probably need to solve search engine interfaces for the app as
>>> well.
>>>
>>> BTW, I got the ASDoc in the CI server to work again. Here are links to
>>> the SWF version [1] and JS version[2].
>>>
>>> -Alex
>>>
>>> [1]
>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachefle <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachefle>
>>> xbuild.cloudapp.net <http://xbuild.cloudapp.net/>%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSucce&data=
>>> 02%7C01%7C%7C46e612dfe85445e0789308d4acfda6ad%7Cfa7b1b5a7b34438794aed2c17
>>> 8decee1%7C0%7C0%7C636323652817901308&sdata=s8fFgxBrse1R0EYwAuEQmDD9QSQFkw
>>> lDDmQFoc9dNWU%3D&reserved=0
>>> ssfulBuild/artifact/examples/flexjs/ASDoc/bin-debug/ASDoc.html
>>>
>>> [2]
>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachefle <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachefle>
>>> xbuild.cloudapp.net <http://xbuild.cloudapp.net/>%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSucce&data=
>>> 02%7C01%7C%7C46e612dfe85445e0789308d4acfda6ad%7Cfa7b1b5a7b34438794aed2c17
>>> 8decee1%7C0%7C0%7C636323652817901308&sdata=s8fFgxBrse1R0EYwAuEQmDD9QSQFkw
>>> lDDmQFoc9dNWU%3D&reserved=0
>>> ssfulBuild/artifact/examples/flexjs/ASDoc/bin/js-debug/index.html
>>>
>>> On 6/6/17, 8:46 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> What do the annotations look like?
>>>>
>>>> Maybe there should be some kind of manifest that documents beads and
>>>> their relationships?
>>>>
>>>>
>>>>> On Jun 6, 2017, at 5:46 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> Definitely needs more.
>>>>>
>>>>> In the ASDoc example, there is a checkbox to see just view beads. I
>>>>> have
>>>>> added ASDoc annotations to the view beads so they show up when that
>>>>> filter
>>>>> is on. I'm sure view beads may have been added since I first did
>>>>> that,
>>>>> and maybe the annotation accidentally got copied into new beads that
>>>>> aren't view beads, but that's my idea for how to find tools in the
>>>>> toolbox.
>>>>>
>>>>> If folks like it, please add more annotations and propose and
>>>>> implement
>>>>> how to generalize the filtering so it isn't 40 checkboxes some day.
>>>>>
>>>>> BTW, the ASDoc example on the CI server is broken. That'll be my
>>>>> stop-ship release bug for today. Until then, you can build the
>>>>> example
>>>>> locally and see how the checkbox works.
>>>>>
>>>>> Thanks,
>>>>> -Alex
>>>>>
>>>>> On 6/5/17, 10:58 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>> One of the most difficult part of dealing with FlexJS and beads is
>>>>>> knowing what beads are available and what beads are interchangeable.
>>>>>>
>>>>>> I think we need a system to programmatically be able to look up bead
>>>>>> and
>>>>>> strand relationships. This could be used by documentation as well as
>>>>>> tooling to give hints as to what beads to use.
>>>>>>
>>>>>> I think there’s been some discussion already on this, but I’m kind of
>>>>>> fuzzy and it probably needs some more.
>>>>>>
>>>>>> Harbs
Re: Finding tools in the toolbox
Posted by Alex Harui <ah...@adobe.com.INVALID>.
You are welcome to add a new tag. Could be something like
@workswith classOrInterface
Or maybe @knownstrands.
I'm not sure what you visualize for "display hierarchy" and "code
hinting". Fundamentally, we have raw data in .json files and you can
write code to process and visualize that data.
I would prefer that folks hold off on adding new tags until after we get
the release out and merge the release branch back to develop. Otherwise,
I think it will increase the likelihood of merge conflicts.
-Alex
On 6/6/17, 10:01 AM, "Harbs" <ha...@gmail.com> wrote:
>It seems like there should be a mechanism to add arbitrary tags that
>include references to acceptable components. Maybe use interfaces to
>indicate swap-ability?
>
>What format would be best for tooling to display hierarchy and code
>hinting? Should there be a manifest file, or is the ASDoc enough for that?
>
>> On Jun 6, 2017, at 7:51 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> View beads have @viewbead ASDoc tag
>> Top-level components have @toplevel ASDoc tag.
>>
>> All tags are output to tags.json and the ASDoc example could implement
>>any
>> sort of filtering based on those tags. New tags I think can be added by
>> just adding them to the ASDoc and maybe telling the compiler to hide it
>> from Google Closure.
>>
>> That's why I see the need for something that is more of an "application"
>> for our documentation. The app can compute relationships based on data.
>> Volunteers are encouraged to improve this capability for our ASDoc. We
>> also probably need to solve search engine interfaces for the app as
>>well.
>>
>> BTW, I got the ASDoc in the CI server to work again. Here are links to
>> the SWF version [1] and JS version[2].
>>
>> -Alex
>>
>> [1]
>>
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachefle
>>xbuild.cloudapp.net%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSucce&data=
>>02%7C01%7C%7C46e612dfe85445e0789308d4acfda6ad%7Cfa7b1b5a7b34438794aed2c17
>>8decee1%7C0%7C0%7C636323652817901308&sdata=s8fFgxBrse1R0EYwAuEQmDD9QSQFkw
>>lDDmQFoc9dNWU%3D&reserved=0
>> ssfulBuild/artifact/examples/flexjs/ASDoc/bin-debug/ASDoc.html
>>
>> [2]
>>
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachefle
>>xbuild.cloudapp.net%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSucce&data=
>>02%7C01%7C%7C46e612dfe85445e0789308d4acfda6ad%7Cfa7b1b5a7b34438794aed2c17
>>8decee1%7C0%7C0%7C636323652817901308&sdata=s8fFgxBrse1R0EYwAuEQmDD9QSQFkw
>>lDDmQFoc9dNWU%3D&reserved=0
>> ssfulBuild/artifact/examples/flexjs/ASDoc/bin/js-debug/index.html
>>
>> On 6/6/17, 8:46 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> What do the annotations look like?
>>>
>>> Maybe there should be some kind of manifest that documents beads and
>>> their relationships?
>>>
>>>
>>>> On Jun 6, 2017, at 5:46 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>wrote:
>>>>
>>>> Definitely needs more.
>>>>
>>>> In the ASDoc example, there is a checkbox to see just view beads. I
>>>> have
>>>> added ASDoc annotations to the view beads so they show up when that
>>>> filter
>>>> is on. I'm sure view beads may have been added since I first did
>>>>that,
>>>> and maybe the annotation accidentally got copied into new beads that
>>>> aren't view beads, but that's my idea for how to find tools in the
>>>> toolbox.
>>>>
>>>> If folks like it, please add more annotations and propose and
>>>>implement
>>>> how to generalize the filtering so it isn't 40 checkboxes some day.
>>>>
>>>> BTW, the ASDoc example on the CI server is broken. That'll be my
>>>> stop-ship release bug for today. Until then, you can build the
>>>>example
>>>> locally and see how the checkbox works.
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>> On 6/5/17, 10:58 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> One of the most difficult part of dealing with FlexJS and beads is
>>>>> knowing what beads are available and what beads are interchangeable.
>>>>>
>>>>> I think we need a system to programmatically be able to look up bead
>>>>> and
>>>>> strand relationships. This could be used by documentation as well as
>>>>> tooling to give hints as to what beads to use.
>>>>>
>>>>> I think there’s been some discussion already on this, but I’m kind of
>>>>> fuzzy and it probably needs some more.
>>>>>
>>>>> Harbs
>>>>
>>>
>>
>
Re: Finding tools in the toolbox
Posted by Harbs <ha...@gmail.com>.
It seems like there should be a mechanism to add arbitrary tags that include references to acceptable components. Maybe use interfaces to indicate swap-ability?
What format would be best for tooling to display hierarchy and code hinting? Should there be a manifest file, or is the ASDoc enough for that?
> On Jun 6, 2017, at 7:51 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> View beads have @viewbead ASDoc tag
> Top-level components have @toplevel ASDoc tag.
>
> All tags are output to tags.json and the ASDoc example could implement any
> sort of filtering based on those tags. New tags I think can be added by
> just adding them to the ASDoc and maybe telling the compiler to hide it
> from Google Closure.
>
> That's why I see the need for something that is more of an "application"
> for our documentation. The app can compute relationships based on data.
> Volunteers are encouraged to improve this capability for our ASDoc. We
> also probably need to solve search engine interfaces for the app as well.
>
> BTW, I got the ASDoc in the CI server to work again. Here are links to
> the SWF version [1] and JS version[2].
>
> -Alex
>
> [1]
> http://apacheflexbuild.cloudapp.net:8080/job/FlexJS_ASDoc_Example/lastSucce
> ssfulBuild/artifact/examples/flexjs/ASDoc/bin-debug/ASDoc.html
>
> [2]
> http://apacheflexbuild.cloudapp.net:8080/job/FlexJS_ASDoc_Example/lastSucce
> ssfulBuild/artifact/examples/flexjs/ASDoc/bin/js-debug/index.html
>
> On 6/6/17, 8:46 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> What do the annotations look like?
>>
>> Maybe there should be some kind of manifest that documents beads and
>> their relationships?
>>
>>
>>> On Jun 6, 2017, at 5:46 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> Definitely needs more.
>>>
>>> In the ASDoc example, there is a checkbox to see just view beads. I
>>> have
>>> added ASDoc annotations to the view beads so they show up when that
>>> filter
>>> is on. I'm sure view beads may have been added since I first did that,
>>> and maybe the annotation accidentally got copied into new beads that
>>> aren't view beads, but that's my idea for how to find tools in the
>>> toolbox.
>>>
>>> If folks like it, please add more annotations and propose and implement
>>> how to generalize the filtering so it isn't 40 checkboxes some day.
>>>
>>> BTW, the ASDoc example on the CI server is broken. That'll be my
>>> stop-ship release bug for today. Until then, you can build the example
>>> locally and see how the checkbox works.
>>>
>>> Thanks,
>>> -Alex
>>>
>>> On 6/5/17, 10:58 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> One of the most difficult part of dealing with FlexJS and beads is
>>>> knowing what beads are available and what beads are interchangeable.
>>>>
>>>> I think we need a system to programmatically be able to look up bead
>>>> and
>>>> strand relationships. This could be used by documentation as well as
>>>> tooling to give hints as to what beads to use.
>>>>
>>>> I think there’s been some discussion already on this, but I’m kind of
>>>> fuzzy and it probably needs some more.
>>>>
>>>> Harbs
>>>
>>
>
Re: Finding tools in the toolbox
Posted by Alex Harui <ah...@adobe.com.INVALID>.
View beads have @viewbead ASDoc tag
Top-level components have @toplevel ASDoc tag.
All tags are output to tags.json and the ASDoc example could implement any
sort of filtering based on those tags. New tags I think can be added by
just adding them to the ASDoc and maybe telling the compiler to hide it
from Google Closure.
That's why I see the need for something that is more of an "application"
for our documentation. The app can compute relationships based on data.
Volunteers are encouraged to improve this capability for our ASDoc. We
also probably need to solve search engine interfaces for the app as well.
BTW, I got the ASDoc in the CI server to work again. Here are links to
the SWF version [1] and JS version[2].
-Alex
[1]
http://apacheflexbuild.cloudapp.net:8080/job/FlexJS_ASDoc_Example/lastSucce
ssfulBuild/artifact/examples/flexjs/ASDoc/bin-debug/ASDoc.html
[2]
http://apacheflexbuild.cloudapp.net:8080/job/FlexJS_ASDoc_Example/lastSucce
ssfulBuild/artifact/examples/flexjs/ASDoc/bin/js-debug/index.html
On 6/6/17, 8:46 AM, "Harbs" <ha...@gmail.com> wrote:
>What do the annotations look like?
>
>Maybe there should be some kind of manifest that documents beads and
>their relationships?
>
>
>> On Jun 6, 2017, at 5:46 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Definitely needs more.
>>
>> In the ASDoc example, there is a checkbox to see just view beads. I
>>have
>> added ASDoc annotations to the view beads so they show up when that
>>filter
>> is on. I'm sure view beads may have been added since I first did that,
>> and maybe the annotation accidentally got copied into new beads that
>> aren't view beads, but that's my idea for how to find tools in the
>>toolbox.
>>
>> If folks like it, please add more annotations and propose and implement
>> how to generalize the filtering so it isn't 40 checkboxes some day.
>>
>> BTW, the ASDoc example on the CI server is broken. That'll be my
>> stop-ship release bug for today. Until then, you can build the example
>> locally and see how the checkbox works.
>>
>> Thanks,
>> -Alex
>>
>> On 6/5/17, 10:58 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> One of the most difficult part of dealing with FlexJS and beads is
>>> knowing what beads are available and what beads are interchangeable.
>>>
>>> I think we need a system to programmatically be able to look up bead
>>>and
>>> strand relationships. This could be used by documentation as well as
>>> tooling to give hints as to what beads to use.
>>>
>>> I think there’s been some discussion already on this, but I’m kind of
>>> fuzzy and it probably needs some more.
>>>
>>> Harbs
>>
>
Re: Finding tools in the toolbox
Posted by Harbs <ha...@gmail.com>.
What do the annotations look like?
Maybe there should be some kind of manifest that documents beads and their relationships?
> On Jun 6, 2017, at 5:46 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Definitely needs more.
>
> In the ASDoc example, there is a checkbox to see just view beads. I have
> added ASDoc annotations to the view beads so they show up when that filter
> is on. I'm sure view beads may have been added since I first did that,
> and maybe the annotation accidentally got copied into new beads that
> aren't view beads, but that's my idea for how to find tools in the toolbox.
>
> If folks like it, please add more annotations and propose and implement
> how to generalize the filtering so it isn't 40 checkboxes some day.
>
> BTW, the ASDoc example on the CI server is broken. That'll be my
> stop-ship release bug for today. Until then, you can build the example
> locally and see how the checkbox works.
>
> Thanks,
> -Alex
>
> On 6/5/17, 10:58 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> One of the most difficult part of dealing with FlexJS and beads is
>> knowing what beads are available and what beads are interchangeable.
>>
>> I think we need a system to programmatically be able to look up bead and
>> strand relationships. This could be used by documentation as well as
>> tooling to give hints as to what beads to use.
>>
>> I think there’s been some discussion already on this, but I’m kind of
>> fuzzy and it probably needs some more.
>>
>> Harbs
>
Re: Finding tools in the toolbox
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Definitely needs more.
In the ASDoc example, there is a checkbox to see just view beads. I have
added ASDoc annotations to the view beads so they show up when that filter
is on. I'm sure view beads may have been added since I first did that,
and maybe the annotation accidentally got copied into new beads that
aren't view beads, but that's my idea for how to find tools in the toolbox.
If folks like it, please add more annotations and propose and implement
how to generalize the filtering so it isn't 40 checkboxes some day.
BTW, the ASDoc example on the CI server is broken. That'll be my
stop-ship release bug for today. Until then, you can build the example
locally and see how the checkbox works.
Thanks,
-Alex
On 6/5/17, 10:58 PM, "Harbs" <ha...@gmail.com> wrote:
>One of the most difficult part of dealing with FlexJS and beads is
>knowing what beads are available and what beads are interchangeable.
>
>I think we need a system to programmatically be able to look up bead and
>strand relationships. This could be used by documentation as well as
>tooling to give hints as to what beads to use.
>
>I think there’s been some discussion already on this, but I’m kind of
>fuzzy and it probably needs some more.
>
>Harbs