This is a great discussion! The fact is, the current component set
needs modernization to be more easily extensible, styleable, etc. It's
an old code base that's been brought along as the runtime has been
modernized. There's lots of room for improvement!
Right now the OpenLaszlo team is focused on Flash 9 support, which
promises to bring huge performance benefits. As you know, rewriting
components is a big job and something do plan to do with the community's
help.
Of course, we'd love any contributions, even if it's just towards the
design. It would be great to get some more specifics about which design
choices you made, and why. For example, what about the existing
selection and drag/drop management didn't work for you? Were things
broken or did you just need to extend them?
Also, it sounds like some of the smaller bits could be very useful to
the community, e.g. subcommands, especially if they are integrated into
the LFC.
It's really valuable to know what problems you faced with the language
and any APIs and extension points you needed so we can make sure they're
addressed in the next round.
And yes, I agree fully about XML models needing to send a 'delete'
event. REST support is critical - what issues are you seeing? I want
to make sure this is working.
Thanks for being a part of the community, and giving such astute feedback!
Greg Denton wrote:
I have no plans to open source due to (1) the time required, (2) the
fact that my components are not complete and not stylable either, and
(3) the feeling that since much of the power of the framework rests on
(tight) integration with the special "xml model" layer it would not be
as valuable to others.
It would require a bit of work to redesign for less coupling between
these subsystems (for "mixing and matching"). I also took a lot of
performance shortcuts/improvements by favoring callbacks over events.
The subsystems are all pretty tightly integrated:
- recoding of form components for my own graphic look and to be data
driven using the xml model code
- extension to command functionality for execution and subcommands,
tied to context menus and selection
- selection management: tied to commands, extended tree and form
selection, window activation
- drag/drop: special dragger code, integrated with sink registration
- xml models supporting "deleting" notifications, undo/redo, cross
references/dependencies between objects
Oddly, after all this work there is a hard show stopper for me: lack
of REST support for SOLO apps :(.
If you would like some input to a discussion of OL frameworks let me know.
On Mon, Jun 30, 2008 at 9:27 PM, Simon Cornelius P. Umacob
<[EMAIL PROTECTED]> wrote:
Hi,
Leonardo Mateo wrote:
On Wed, Jun 18, 2008 at 8:17 PM, Dave Miller <[EMAIL PROTECTED]> wrote:
On Wed, Jun 18, 2008 at 1:28 PM, Greg Denton wrote:
A sympathetic note....#2 is a real pain. I asked the same question a
while back. I wound up rewriting all of the component classes (using
the base classes) that my app uses as the lz ones are so ugly and only
minimally styleable (color, font). It turns out that the data handling
for the components was not what I liked anyway, and I needed to do
selection management, so it was inevitable. I had to create a whole
application framework to do what I wanted. Lots of time. What I have
now is valuable (in terms of functionality) but has to be closely
maintained. I'm sure a lot of developers are doing the same thing.
Do you guys have plans on open sourcing some of your components? Maybe we
can work together on writing custom components or something... =)
[ simon.cpu ]
p.s.: Any news on regex support for edittext?
--
And /usr/games/fortune futurama says:
Pop a Poppler in your mouth
When you come to Fishy Joe's
What they're made of is a mystery
Where they come from no one knows
You can pick 'em you can lick 'em you can chew 'em you can stick 'em
If you promise not to sue us you can shove one up your nose.
--
Regards,
Max Carlson
OpenLaszlo.org
