It's open source on github at: https://github.com/LUCA-Studios-LLC/LUCA-UI-Framework-for-Dart
It's in the very early stages, as Dart is, but coming along nicely I
think.
On Nov 23, 3:01 pm, John <pruj...@gmail.com> wrote:
> http://phylotic.blogspot.com/2011/11/update-on-luca-ui-framework-for-...
The editor is my biggest frustration so far (I've been using the
feedback button quite a bit), but I know that will come along and
consider it the cost of doing business on the bleeding edge.
Regarding my project, ultimately I would like to provide some sort of
tooling capability to link declarative xml files directly with the
Dart editor. So the developer could have "strongly typed" access to
an xml-based representation of a layout. This would be something
analogous to what WPF/Silverlight does in Visual Studio with
"UserControl". I think the Android plug-in for eclipse has something
similar. Any plans for this type of extensible for the Dart editor?
John
On Nov 23, 1:15 pm, Bob Nystrom <rnyst...@google.com> wrote:
> On Wed, Nov 23, 2011 at 6:01 AM, John <pruj...@gmail.com> wrote:
>
> >http://phylotic.blogspot.com/2011/11/update-on-luca-ui-framework-for-...
VerticalPanel vp = new VerticalPanel();
vp.add(new TextBox());
You'd do something like
VerticalPanel vp {
TextBox searchBox {
keyUp => doSearch()
text "enter query to search"
}
VerticalPanel searchResults {
}
}
to define a domain specific search UI. If it turns out a generic
searchbox makes sense to develop, you'd be able to write a new class
SearchBox, which has builtin background hourglass image, and a
specialized search function. It might look something like this:
VerticalPanel vp {
SearchBox searchBox {
search => doSearch()
}
VerticalPanel searchResults {
}
}
Just sharing rough thoughts here.
I don't think using xml is a good idea though. There are very valid
arguments that xml is not really humanly-readable (as claimed often
with xml).
Note that SearchBox in above example would be just a regular Dart
class, the UI dsl just defines an instance. A SearchBox might have for
example a getter/setter "backgroundText" i.e. "enter name of author to
search for", which is set invisible when the user focuses on it.
Poorly structured xml, with loose standards, is another matter
entirely.
Thanks Bob. And thanks for the great work you and the team are doing
with Dart. So far I'm finding it to be a very intuitive and powerful
language. I'm really pleased with how far I've been able to go with
this project while Dart is still in alpha stage.
The editor is my biggest frustration so far (I've been using the
feedback button quite a bit), but I know that will come along and
consider it the cost of doing business on the bleeding edge.
Regarding my project, ultimately I would like to provide some sort of
tooling capability to link declarative xml files directly with the
Dart editor.
So the developer could have "strongly typed" access to
an xml-based representation of a layout.
Any plans for this type of extensible for the Dart editor?
I'll take a look at the JSON approach - having something in a format
supported by a native Dart parser is certainly very attractive.
John
On Nov 28, 10:58 am, Bob Nystrom <rnyst...@google.com> wrote:
By the way, where is that JSON parser located?
I'd vote for XML in favour of JSON or YAML here. I know that XML is
out-of-favor these days, but I still think it's great for certain
things, including describing UI layouts.
Specifically, XML provides a clear way of seperating attributes of an
object from it's children object.
This is really clear:
<s:Group alpha="0.5" backgroundColor="#000000">
<s:Checkbox enabled="false" />
</s:Group>
In that it contains a partially visible group with a disabled
checkbox.
IMHO the similar layout described in JSON is more verbose, and less
clear:
group {
alpha: "0.5"
backgroundColor: "#000000"
children {
checkbox {
enabled: "false"
}
}
}
Additionally, XML gives the ability to provide qualified namespaces
(s:Checkbox vs mx:Checkbox - which resolve to the classes
flex.components.spark.Checkbox and flex.components.mx.Checkbox
respectively) where JSON doesn't tend to offer the same.
Also, - I may be a little late in relaying the message but - I think a
UI framework for Dart, which is separate from the DOM is a brilliant
idea.
On Nov 29, 9:40 am, Justin Fagnani <justinfagn...@google.com> wrote:
This is really clear:
<s:Group alpha="0.5" backgroundColor="#000000">
<s:Checkbox enabled="false" />
</s:Group>
In that it contains a partially visible group with a disabled
checkbox.
IMHO the similar layout described in JSON is more verbose, and less
clear:
group {
alpha: "0.5"
backgroundColor: "#000000"
children {
checkbox {
enabled: "false"
}
}
}
I'm hoping to build a capability in my library that is extensible, and
able to consume multiple UI formats, by using a provider model with a
IPresentationParser interface. So Xml and JSON are both on the table
in my view. Although, I prefer XML for readability and namespaces.
The consensus I am hearing, which validates my own thinking, is that
it is important to separate the presentation (design) component from
the implementation (code) component of any UI framework.
However, I think a stripped-down YAML could be the bee's knees:
s-Group:
style: { alpha: 0.5, background: '#000000' }
s-Checkbox: { enabled: false }
(s:Group (alpha 0.5) (background #000000)
(s:Checkbox (enabled false)
)
)