Pedro Viegas wrote:
Steve,
This Cognition framework is sounding better by the minute.
I'm in the middle of creating a base platform for app development
exactly
with T4, Hivemind, Hibernate, so it's really a quick fit for me, it
appears.
Model based code generation ou reverse engeneering is preciselly what I
have
started with, using Hibernate Tools ant scripts with custom velocity
templates.
Tell me Steve are there some catches to app development with
Cognition...
things like, do you have to do things like this or other way, link pages
to
one another for page navigation with a specificly provided feature,
instanciate classes based on these mandatory abstract classes, or
implementing a half a dozen interfaces and extend the method A or B,
only
use these component librarys... you know what I mean kind of
hard-coupled
features.
You generally will not have to do that unless you are extending
Cognition. You also have access to anything you may otherwise do in
Tapestry or Hibernate.
I saw your demo, and was very impressed. It all fits togheter. I also
saw
the dozens of ANT tasks... that scared me a little I must say. All of
this
funcionality with a few mouse clicks is what makes me ask what I did. Is
it
all very strickly linked in a particular and restricted way or is it
just a
quick start witch one can easilly extend and change to ones needs.
There are a lot of ant tasks, we will hide some of them using gui
elements in modeler eventually. They are more important for people who
need to do things outside eclipse, like a continuous build system.
Everything is designed to be extensible, and if you find you can't
extend something using the extension mechanisms such as EditTypes,
SearchTypes or Blocks etc, it should probably be fixed on our end.
You talk of the custom EditTypes we can provide. Are these components?
These are simple classes which end up being contributions to a hivemind
configuration point. In the case of EditTypes, they implement EditType
interface, which is a lot simpler than it sounds because in most cases
you would extend AbstractEditType. Each edit type returns one value that
is then assigned to the correct pojo. A SearchType returns one or more
hibernate filters that are assigned to query. A ViewType can be used to
layout data differently and supports Inserts formatter option and also
uses the same formatter to display a date for example consistently on a
data grid.
What about Page Navigation. Does Cognition provide something for that? I
mean, a very usefull feature in many projects is the ability to produce
Site
Maps, ou bread crumbs for navigation, or even dynamicly generated
hierarchical menus.
Other features like the Structs or JSF visual action based page
navigation
modeler, is there anything planed for these kind of features?
We are currently investigating approaches to web flow as this is
critical feature. The navigation component is likely to enter the scene
during this. We may end up working on a Tapestry implementation of
Spring Web Flow or roll our own using hivemind.
Another issue is AJAX. You say your planning on suporting it. Do you
have it
under way? Is it a soon to apperar feature? I think it's a must have
since
it reduces needed bandwith in a brutal way, and adds a rich client
usability
to prior "submit oriented" pages.
A project comes to mind, Tacos! Are you planning to integrate it? It
seems
to be a must have for any T4 project, even thought it's still Beta. What
do
you plan to do here? Wait till T4.1 with AJAX allready bundled in?
We will likely hold off creating Ajax Cognition components until we are
done with web flow and related designers. But we can certainly add
component libraries like Tacos, I will enter an issue for this. I was
looking at creating some type of composite edit component using taco's,
but its not at the top of my list.
Sorry for the pop quiz! :-)
I'm really curious with Cognition and I'm very motivated to try it on,
but
time is short and I would like to get a better view of it before I drill
in
to it!
I encourage you to check out the SLAVE example application in the
cognition src download here. It'll give you a better idea of how things
work than the viewlet does.
http://dev.thelabllc.com/downloads/cognition/cognition-src.zip
Thanks,
On 3/28/06, Steve Motola <[EMAIL PROTECTED]> wrote:
I don't know if it's clear from the install docs, but:
1. We don't use the Ivy Plugin, and we use Eclipse 3.1 almost
exclusively. We
are going to get into GMF which will force all of us to use
3.2eventually...
2. If you are just using the Modeler, you shouldn't need to install
Ivy.
3. If you are using the Framework solo with src, you will need to have
Ivy
installed to download all the dependency libs. But again this is just
Ivy
installed, not the plug-in.
Is that clearer? Let me know if I need to change install docs. Key is
we
want
people to use it - to play with it and see if it is up to snuff and if
you
think it's the bees knees to start contributing. We can make as many
fancy
presentations as we like but if it can't execute on what it's purported
to
do
it's just more 'emperor's new software'. Please report any fatal bugs
or
impediments to being able to use it, thanks.
It's Alpha, but we did some pretty aggressive QA prior to release so
that
the
community doesn't spend it's time with dumb bugs but can instead focus
on
current and desired functionality.
Quoting Peter Svensson <[EMAIL PROTECTED]>:
I would really like to try it, bu for abscure reasons I run eclipse
3.1,
which the ivy plugin does not support yet :| Anyway, it looks lika a
great
effort, and it would be very interresting to see if you could
loan/borrow/support some of the existing stuff in trails.
Cheers,
PS
On 3/28/06, Steve Motola <[EMAIL PROTECTED]> wrote:
Not trying to take away from Trails, which is a great project and we
cross
some
of the same areas. Chris said they do some of the same stuff but I
got
the
implication from the blog that they did not cover all these
items. We
take
some different approaches but are going to look into how we can
collaborate.
Wow this sounds fantastic! Is it easily possible to reuse your Edit
components in an existing project?
Yes, you can have as many 'Cognition:Edit' components as you like in
a
page /
project. Each is backed by a generated XML file that can be edited.
Currently, all Edit components are tightly coupled with a POJO /
table
and
we
are looking to separate that some to be more flexible to support
multiple
table
forms with transactions.
And are they tight to hibernate objects or would they work for any
object?
Right now Hibernate only. We are looking at supporting other ORMs as
well
as
other datasources other than RDBMSs, but as per Derick in another
thread
we are
using some features unique to Hibernate such as filters in the other
companion
components.
We're also planning to extend them to have 'Ajax enabled' versions as
well.
Anyone want to take this on? ;)
Thanks
Henri.
On 3/28/06, Steve Motola <[EMAIL PROTECTED]> wrote:
Answering Howard's Blog - Wednesday, March 08, 2006 - "From the
fanciful
ideas
category ..."
Wouldn't it be nice if I could just plop the following into the
middle of
my
form?
<span jwcid="@edit:EditObject" object="ognl:pojo"/>
The Cognition Framework Edit component basically works just like
that,
i.e
.:
<span jwcid="[EMAIL PROTECTED]" persistent="ognl:new
com.thelabllc.product.orm.model.Product()" />
Form fields are wrappered Tapestry components called
EditTypes. We
cover
the
basics - text, radio button, propertyselection, etc.
For any new field you can just create a new EditType (EditTypes
are
Hivemind
contributions). For example, if you have a composite field of
three
textboxes
that needs to be validated in a particular way, (i.e. US phone
number)
you create a 'Phone' EditType and then this can be reused within
any
Edit
component easily.
As more people contribute, this has the power to be a very
comprehensive
list of
EditTypes available for any form.
And, of course, some set of annotations to define the validation
of
those
properties.
We do this via XML at this time, using Validators and Translators,
with
editable
defaults put in for most datatypes.
We will have more annotation support for items like this in the
future. The
advantage that the XML provides is that your configuration is not
tied
to
your
code; you can potentially have Nth number of variations on how
you'd
like
to
display your field in a form.
Maybe even so carefully named Block components to provide row
overrides?
Done, you can override form items with a Block.
I think this logic would kick ass when building prototypes.
Time to take names. ;)
http://www.thelabllc.com
........................................
Steve Motola
[EMAIL PROTECTED]
(310) 422-5521
The Lab, LLC
http://www.thelabllc.com
Content is for intended recipient only.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
........................................
Steve Motola
[EMAIL PROTECTED]
(310) 422-5521
The Lab, LLC
http://www.thelabllc.com
Content is for intended recipient only.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
........................................
Steve Motola
[EMAIL PROTECTED]
(310) 422-5521
The Lab, LLC
http://www.thelabllc.com
Content is for intended recipient only.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pedro Viegas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
