I'm not all that up on designing components but assuming its like the
javabeans for guis many years ago, assuming your new component can have
some kind of a properties palette where the application developer can
set new attributes then I'd definitely say make them more extensible and
the RAD will follow.
If there isn't anything like being able to set attributes via a custom
palette or propertysheet then adding that would seem like a good early
step in terms of application developer productivity.
Matt Chotin wrote:
Actually when we posted our component plans
(http://weblogs.macromedia.com/flexteam/archives/2007/02/the_flex_teams.cfm)
we made clear we definitely want the community to participate in
building these things too. Bruce, it sounds like you have a set of
components in mind and I know that there are plenty of folks who watch
both flexcoders and flexcomponents who would love to know what you'd
be interested in paying for. Feel free to send ideas my way, I might
even be able to keep a repository of requests, but I think that there
are plenty of folks out here who would love to hear them as well.
The larger point, as has been made by others, is we can't do
everything at once, and sometimes we decide to advance the framework
rather than focus on individual component improvements (though in some
of these DG cases we are actually looking at incorporating things into
the next release). Rather than saying that you don't want to create a
separate new component for every new feature, maybe you guys should
set up a components project where popular extensions are built into
framework subclasses. Then you can use the extended component that
will cover more of your use-cases, rather than rewriting each time.
Bruce brings up a separate interesting issue though: we sometimes make
decisions in our components to keep them as flexible as possible. The
background color of a row or cell is one example, rather than building
in logic where we weren't sure if we'd cover all cases we made it
possible to implement by writing a subclass. This particular decision
is a compromise between extensibility and RAD capabilities (if you'll
allow me to make a gross generalization). How many of you would
prefer we make things more RAD capable at the potential expense of
extensibility? Are you willing to make a tradeoff? I know the answer
you really have is "both," but if you had to make a choice would you
tell us to go down the RAD path?
Matt
------------------------------------------------------------------------
*From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED]
*On Behalf Of *Gordon Smith
*Sent:* Tuesday, February 20, 2007 3:00 PM
*To:* flexcoders@yahoogroups.com
*Subject:* RE: [flexcoders] Gordon Smith - Some Answers about the Datagrid
> please create more components and charge extra for them. I could give
you a list of about 20
that would have a value to most business developers.
I'm sure the frameworks team would be interested in seeing your list.
Please post it on flexcoders or send it to our product manager Matt
Chotin at [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>.
- Gordon
------------------------------------------------------------------------
*From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED]
*On Behalf Of *boy_trike
*Sent:* Tuesday, February 20, 2007 2:20 PM
*To:* flexcoders@yahoogroups.com
*Subject:* [flexcoders] Gordon Smith - Some Answers about the Datagrid
--- In flexcoders@yahoogroups.com
<mailto:flexcoders%40yahoogroups.com>, "Gordon Smith" <[EMAIL PROTECTED]> wrote:
> After all, we
> can't provide every feature that developers need without bloating our
> components, and we've assumed that subclassing will be a commonly used
> technique.
Gordon: Instead of making components FATTER, create MORE components.
Just like there
is a vertical and horiz. grid. I used to have a T-shirt that said "he
who dies with the most
toys wins" Let me paraphrase, "He who has the MOST components wins "
(with faster,
more focused solutions" Just like the chart components are an extra
price option, please
create more components and charge extra for them. I could give you a
list of about 20
that would have a value to most business developers. (esp. those
getting paid a fair
amount for their work.
> By the way, when you say "for each cell" do you mean that each cell
> needs to render differently based on the data it displays? Or every row
> might be different, but each column in a row is the same? Or that each
> column is different, but every row in a column is the same?
>
I mean EACH cell, not row or column. while alt. coloring of rows is
asthetically pleasing,
and coloring columns can make one stand out, I want to solve a
business problem (i.e.
customers over credit limit have that amount in bold, Orders over 90
days have the due
date in RED
Bruce
