Hey,
My feedback inline.
On Fri, 29 Jul 2011 12:36:26 +0800, Rickard Öberg wrote:
* Templates for common app structures, where developers "fill in the
blanks", e.g. "domain goes here, app services here, REST goes here".
Convention over configuration, but architecturally as well as on the
code. With the recent ClassScanner tool, this can even be "put these
kinds of classes in this package", and the ClassScanner can pick them
up automatically.
This would really lower the entry barrier, see my comments on
documentation.
* IDE plugins. We have Envisage now, but it is getting outdated. I
would like to change it into something like a IDEA plugin where you
can click "Refresh" (like the Gradle plugin), and it would show you
what your app looks like. Now that assembly is getting to a point
where you don't necessarily have to instantiate the app that is
created, this should be relatively easy
I don't have anything usefull to say about IDE plugins as I don't use
them much.
I could live well with any good java code editor alone (classpaths,
autocomplete).
Actually, and just for info, I still use Netbeans to write Qi4j code
reusing the
poms generated by gradle to get the IDE classpaths rights. It works for
me.
* Support for traditional technologies, specifically on the DB side.
We need to support storing data in SQL databases easily, for the
simple reason that admins know how to manage and backup these
critters. As simple as that. They can also provide scaling features,
if necessary.
At my shop, software editor, we use a Qi4j app embedded in a JEE app.
Each one
of them have its database. All this is using XADataSources managed by
the JEE
container. DataSource are wrapped before being used by the SQL
EntityStore so
that's the JEE container (or JEE app code) responsibility to issue the
commits.
The only limitation we have is to play one UoW only per request and
that suited
our use cases. The final product has backup/restore and HA facilities
eased by
the fact that all storage is done in SQL databases. Today it is used
successfuly
in production at several places with tens of thousands users.
* More support for NOSQL. Adding e.g. CouchDB and MongoDB should be
trivial. I don't know how much these are actually used, but adding
them as EntityStores should a simple exercise, so why not?
I don't use any of theses so I don't know.
* Support for standard JSR's, such as 303 (Validation) and 330
(Injection), should be reasonably easy to do, and lowers the learning
curve on these things. Validation and Injection is a big part of
every
day work, so this is important.
About Validation I guess that would mean something like being able to
use JSR303
based annotations to apply Qi4j Contraints. Right?
About Injection, would that mean supporting at least the @Inject/@Named
annotations and the Provider type?
I'm personnaly convinced (mostly by you Rickard :) ) that JSR330 is
wrong and I
don't know if supporting it would ease the learning curve.
So that's my 0 cents on this one ...
* Documentation. I've said this before, and I suck at doing it, but
it's still important. Documenting the basics, as well as common
patterns. I still feel like we need some kind of wiki-style website
for this to be really easy to do.
I tried to bring some 'new blood' to Qi4j but despite the fact that all
of them
told me "there's a lot to read", being happy with that, only a few got
a good
grasp on the technology because they missed both big picture tutorials
and
getting started tutorials taking them by the hand from getting the sdk,
setting up their classpaths rights to a running example. The
"application
templates" could be a great source for good tutorials.
* Getting a full stack. The main missing point to get a "full stack",
as it is, is the REST part. I have this, and can port it to Qi4j, so
that should be doable. Once that is in place we have a good
end-to-end
stack for building apps, I think.
I'm really interested on this one, I'm building REST webservices using
Qi4j and
I'm sure I already reinveted some of your wheels there.
So those are my thoughts on this. Is it doable? Or should I give up
on this? Is it possible to get any meaningful "marketshare" with
Qi4j,
if v2.0 has all of the above? What is important? What is not
important? What do you guys think?
No please, don't give up, Qi4j is important!
I'd be happy to help by working on extensions and libraries.
I'm working on an opensource project using Qi4j, maybe it could give
some
visibility to it once/if it get some. If projects using Qi4j get
visibility,
Qi4j itself get some of it. What about a PoweredBy page on the site and
a
"PoweredBy Qi4j" official logo? BTW, has the StreamFlow project been
finally
opensourced?
/Paul
--
Paul Merlin - eskatos.github.com
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
