Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

There's been an interesting thread going on in incubator@a.o [1] about 
(a) the number of podlings in the incubator and (b) how long some of 
them are taking to graduate.  One of the main points being made is that 
podlings that have been in the incubator for a certain period of time 
(no-one is suggesting how long exactly, but 1 year is being used as a 
strawman in the thread) should be more explicit in defining their 
roadmap and action steps towards graduation.

To be honest, this is all very reasonable, but from Isis' point of view 
it is perhaps slightly worrying, because although we've made some 
progress with getting our code etc together (and the licenses, ICLAs, 
release processes etc are in good shape), we haven't made a lot of 
progress in attracting new committers.  Indeed, arguably we've gone 
backwards in that space: right now only Kevin, Rob and myself currently 
actively commit.

With that in mind, Kevin, Rob and I had a skype conf call this weekend 
to discuss some ideas to move Isis forward towards graduation.  
Obviously, this is it's slightly against Apache policy ("if it didn't 
happen on the mailing list then it didn't happen"), which is why I'm 
posting here now to post some of our initial conclusions and to broaden 
out the discussion to everyone else who might be interested.  (Kevin and 
Rob: correct me if I overstate on any of this).


*Marketing Message*

The main thing we discussed was the "marketing message" for Isis.

/Automatic UI/

The view we came to was that the automatic-UI generation part of Isis 
(ie the naked objects pattern) is possibly more of a negative than a 
positive, at least so far as attracting new users:
* That is, for those that have heard of naked objects (guestimate: 1/4 
to 1/3 of developers), chances are that they have dismissed it as being 
a way to build over-simplified CRUD-style applications.  (Of course, 
those of us who have actually used it to build apps know that ain't so, 
but that's a different discussion).
* For those that have not heard of naked objects, the proposition that 
"here's a framework that will automatically generate your UIs" doesn't 
resonate.  Why? I guess we can speculate; my view is that there are now 
plenty of UI technologies that are quite productive/easy to use/fun; 
probably a lot more so than when the original naked objects framework 
was developed c: 2000.  Another reason might be that developers put too 
much emphasis over owning the UI rather than making sure the domain 
model is good.

On the other hand, we did conclude that the automatic-UI is useful as a 
design tool, and would-be users of Isis could probably understand it in 
those terms.  The fact that the automatic UI is also suitable for use by 
end-users in some situations is subsidiary and something that adopters 
of Isis might discover only later on.

/REST/

Another point that I was keen to see factored into the marketing message 
for Isis is its REST support (the json-viewer).  As you may have picked 
up from other posts, I've been developing a standalone spec, Restful 
Objects [2], which defines defines a set of RESTful resources, and 
corresponding JSON representations, for accessing and manipulating a 
domain object model.

I'm quite excited by this Restful stuff.  On the one hand, as well as 
Isis' implementation, there's also another .NET implementation underway 
via Naked Objects MVC (Richard Pawson has been providing great feedback 
on the spec).  And Johan Andries has been making good progress on a new 
RESTful UI, which I'm hoping might go open source.  Also, the REST 
approach has met a good reaction at our (joint) client in Ireland.

In terms of marketing, my view is that REST is an area where there is 
currently a lot of interest, but developers looking into it will likely 
realise that it's a complex area to do right (ful support for HATEOAS, 
HTTP headers and status codes etc).  As such, developers might be 
interested in a framework that can help them out, at a somewhat higher 
level of abstraction than JSR-311.  The proposition is: press a button 
and get a complete, fully restful API to any domain model.

/DDD/

A third message is for those that are interested in domain 
modelling/domain driven design, for whom the automatic UI might (again) 
be a useful design tool who might want to deploy their app on some other 
framework, eg Spring or JEE.

So, overall this gives us three target use cases to address.  The view 
we took on was that the home page should reflect these use cases:
- domain modelling (and deploy on own platform)
- REST
- automatically generated webapp (primarily to support the other two use 
cases, but optionally as a deployment in its own right)

With this in mind I've sketched up a new graphic that could be used for 
the home page, see [3].  The current home page (the hexagonal 
architecture) would probably be demoted to a supporting page describing 
the architecture of Isis.

In addition, we thought that the side bar menu should be restructured 
around these use cases.


*Alpha status viewers*

Another point we discussed was the incomplete nature of some of the 
viewers.  Having would-be users come across code that is broken is 
clearly not a good experience, at least if there expectations are that 
everything works.

Specifically:
* the scimpi viewer is code complete but its supporting documentation is 
incomplete
* the wicket viewer is not complete (though it's documentation is pretty 
good!)
* the xhtml viewer (which is a precursor to the json viewer, but using 
XHTML representations) is superceded by the json viewer and so should be 
removed
* the dnd viewer (which has worked in the past), is currently broken 
(doesn't repaint properly)

We discussed the dnd viewer quite a lot.  Although it is, in some sense, 
the "purest" expression of the naked objects pattern (bringing in some 
of the original ideas of expressive systems), the truth, probably, is 
that for our target audience this isn't important to emphasise.  Crudely 
put: would-be users are not going to understand what the somewhat 
unconventionaly UI that the dnd browser provides is trying to achieve.  
The fact that it is currently broken hardly helps atters.

So one of the points we thought made sense was to change things so that 
the HTML viewer is the default, rather than DnD.

In terms of the documentation and the site, we decided that the web site 
pages for the scimpi, wicket and dnd viewers should indicate that they 
are "alpha" status, and on the left hand menu we should group them under 
"other viewers".  As such, we probably should remove them from the Maven 
archetype until such time that they are back to production quality.


*Remoting*

We also discussed the remoting component.  The remoting component 
enables the dnd viewer to be deployed in a client/server configuration, 
and is what is used in the big Irish project (on the old .NET version of 
the naked objects framework).  However, my personal view is that 
remoting is, well, broken.  In fact, I think it should be removed: (a) 
the caching semantics for client-side domain objects is not 
well-defined; (b) anyone wanting a client/server solution would probably 
look towards an approach that uses REST, (c) the remoting support 
introduces a lot of complexity in the default runtime (notably, the 
separation of the "Persistor" API and the "ObjectStore" API).

However, we didn't necessarily all agree on this viewpoint.  So for now, 
we decided to de-emphasise remoting, because it doesn't fit into the 3 
main use cases that we highlighted above.  That means that it won't 
appear in the left-hand menu, for example.  My suggestion is that we 
link to it from the dnd viewer page (because that's the only viewer that 
would make use of it).


*Release*

Kevin has been working through the release procedures that I documented, 
and made some changes and clarifications.  I think that by-and-large 
they are holding up ok.

I offered to push out a new release, because we are well overdue for 
another release.   I propose to do this once we've restructured the site 
a little (assuming that we go with the ideas I'm summarizing in this 
thread).


*Blogging*

In terms of building up a community, I suggested that we need to be more 
organized about blogging.  A little organization here between the 
contributors could substantially increase Isis' reach:

* one idea is that Rob, Kevin and I take it in turns to publish a blog 
post such that there is at least one new blog post every week
* blog posts should also be cross posted to blogs.apache.org (which will 
hit some other aggregators)
* publicise blog posts in twitter using #apache #isis hashtags
* publicise blog posts via dzone.com (and any other places you might choose)
* publicise blog posts via isis-dev mailing list, and ask others to 
up-vote in dzone).

In terms of content, one question raised was what, exactly, to blog 
about.  My thoughts are:
* choose a theme for a series of blogs:
    - eg tips-n-tricks taken from applications working on (Robert's 
PlanChaser, or Kevin's various apps)
    - copy-n-paste some of the sidebars from the Richard/Robert's 
original Naked Objects book (for Robert)
    - work through some of the applib conventions, eg how to do choices 
for a property.

In terms of "how to":
* keep it short, something that won't take more than 2 or 3 minutes to read
* if you have more than that, then leave it to the next part
* sit down and write 2 or 3 posts at a time (or split up a draft blog 
post that's got too long) and then only publish them according to a schedule


*Articles***

Rob, Kevin and I didn't discuss writing articles in our call; clearly 
some articles would be good (eg infoq.com or theserverside.com), but it 
takes that much more time to do.  I'd rather focus on just getting a 
steady stream of blog posts going first.


*Thoughts?*

OK, I think that more or less summarises the points that I wanted to 
raise.  If anyone has any views on this/clarifications/corrections, then 
post them here.

Meantime, I intend to put some additional material on blogging up onto 
our wiki.


Thanks,
Dan

[1] http://osdir.com/ml/general.incubator.apache.org/2011-11/msg00182.html
[2] http://restfulobjects.org/
[3] https://cwiki.apache.org/confluence/display/ISIS/RevampedSiteIdeas

Re: Thoughts on how to grow our community.

[Bilgin Ibryam <bi...@gmail.com>]

On 1 December 2011 05:59, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> Hi Bilgin,
> thanks for your thoughts here.  I remember doing that lightning talk at last
> years LJC open conf, only shame that I couldn't make it to this years.
>
> It is, actually, really easy to use Isis domain models in other frameworks,
> but we don't really explain how particularly well.  Hopefully the new site
> will make it clearer that this is an option and have some better information
> here.
>
> I've been working on the online demo, and hope to have it hosted and running
> in the next day or two.  It combines the HTML and JSON (REST) viewers into a
> single WAR, so the user can switch between either view.  If you're
> interested in a sneak peak, its in SVN at examples/onlinedemo.
>
> Your idea of having a special JIRA list for would-be contributors to tackle
> is a great one; I'll try to go through them and categorize them some how.
>  Do you know how other Apache projects do this, by the way?

Yes,  Apache Camel is a good example, you can see in this page
http://camel.apache.org/contributing.html  there is "easy to resolve
issues" link pointing to jira and shows only issues with estimated
complexity - novice.

HTH
Bilgin


>
> Thanks
> Dan
>
>
> On Monday, 28 November 2011, Bilgin Ibryam wrote:
>>
>> Hi Dan  and others,
>>
>> I think this is a really good start for some changes in ISIS.
>> Coming from another Apache full-stack business app  oriented framework
>> (Apache OFBiz) I find ISIS really interesting.
>>
>> Personally after reading the NO book and going through the examples, I
>> found it hard to dive deeper into the framework, many viewers and
>> deployment models... made it hard to focus on and understand the core
>> functionality of the framework. So I strongly support the cleanup of
>> the viewers and having in the base framework only the best (full and
>> clean) implemented one as a reference.
>>
>> Another thing is that ISIS is a full-stack framework and not simply a
>> tool which can be used as part of another project or development
>> process, thus make it hard to use in real life projects.
>>
>> some other notes:
>> I couldn't see a list(jira filter) for issues that can be fixed by
>> newcomers.
>> A running demo on Apache infrastucture would be good demonstration of
>> ISIS features.
>> I heard about ISIS on last year's LJC Open Conference. Giving a 5min
>> lightening talk about ISIS on LJC gatherings would be helpful too.
>>
>> Cheers,
>> Bilgin Ibryam
>>
>>
>> On 21 November 2011 13:02, Dan Haywood <da...@haywood-associates.co.uk>
>> wrote:
>> > There's been an interesting thread going on in incubator@a.o [1] about
>> > (a)
>> > the number of podlings in the incubator and (b) how long some of them
>> > are
>> > taking to graduate.  One of the main points being made is that podlings
>> > that
>> > have been in the incubator for a certain period of time (no-one is
>> > suggesting how long exactly, but 1 year is being used as a strawman in
>> > the
>> > thread) should be more explicit in defining their roadmap and action
>> > steps
>> > towards graduation.
>> >
>> > To be honest, this is all very reasonable, but from Isis' point of view
>> > it
>> > is perhaps slightly worrying, because although we've made some progress
>> > with
>> > getting our code etc together (and the licenses, ICLAs, release
>> > processes
>> > etc are in good shape), we haven't made a lot of progress in attracting
>> > new
>> > committers.  Indeed, arguably we've gone backwards in that space: right
>> > now
>> > only Kevin, Rob and myself currently actively commit.
>> >
>> > With that in mind, Kevin, Rob and I had a skype conf call this weekend
>> > to
>> > discuss some ideas to move Isis forward towards graduation.  Obviously,
>> > this
>> > is it's slightly against Apache policy ("if it didn't happen on the
>> > mailing
>> > list then it didn't happen"), which is why I'm posting here now to post
>> > some
>> > of our initial conclusions and to broaden out the discussion to everyone
>> > else who might be interested.  (Kevin and Rob: correct me if I overstate
>> > on
>> > any of this).
>> >
>> >
>> > Marketing Message
>> >
>> > The main thing we discussed was the "marketing message" for Isis.
>> >
>> > Automatic UI
>> >
>> > The view we came to was that the automatic-UI generation part of Isis
>> > (ie
>> > the naked objects pattern) is possibly more of a negative than a
>> > positive,
>> > at least so far as attracting new users:
>> > * That is, for those that have heard of naked objects (guestimate: 1/4
>> > to
>> > 1/3 of developers), chances are that they have dismissed it as being a
>> > way
>> > to build over-simplified CRUD-style applications.  (Of course, those of
>> > us
>> > who have actually used it to build apps know that ain't so, but that's a
>> > different discussion).
>> > * For those that have not heard of naked objects, the proposition that
>> > "here's a framework that will automatically generate your UIs" doesn't
>> > resonate.  Why? I guess we can speculate; my view is that there are now
>> > plenty of UI technologies that are quite productive/easy to use/fun;
>> > probably a lot more so than when the original naked objects framework
>> > was
>> > developed c: 2000.  Another reason might be that developers put too much
>> > emphasis over owning the UI rather than making sure the domain model is
>> > good.
>> >
>> > On the other hand, we did conclude that the automatic-UI is useful as a
>> > design tool, and would-be users of Isis could probably understand it in
>> > those terms.  The fact that the automatic UI is also suitable for use by
>> > end-users in some situations is subsidiary and something that adopters
>> > of
>> > Isis might discover only later on.
>> >
>> > REST
>> >
>> > Another point that I was keen to see factored into the marketing message
>> > for
>> > Isis is its REST support (the json-viewer).  As you may have picked up
>> > from
>> > other posts, I've been developing a standalone spec, Restful Objects
>> > [2],
>> > which defines defines a set of RESTful resources, and corresponding JSON
>> > representations, for accessing and manipulating a domain object model.
>> >
>> > I'm quite excited by this Restful stuff.  On the one hand, as well as
>> > Isis'
>> > implementation, there's also another .NET implementation underway via
>> > Naked
>> > Objects MVC (Richard Pawson has been providing great feedback on the
>> > spec).
>> > And Johan Andries has been making good progress on a new RESTful UI,
>> > which
>> > I'm hoping might go open source.  Also, the REST approach has met a good
>> > reaction at our (joint) client in Ireland.
>> >
>> > In terms of marketing, my view is that REST is an area where there is
>> > currently a lot of interest, but developers looking into it will likely
>> > realise that it's a complex area to do right (ful support for HATEOAS,
>> > HTTP
>> > headers and status codes etc).  As such, developers might be interested
>> > in a
>> > framework that can help them out, at a somewhat higher level of
>> > abstraction
>> > than JSR-311.  The proposition is: press a button and get

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi Bilgin,
thanks for your thoughts here.  I remember doing that lightning talk at
last years LJC open conf, only shame that I couldn't make it to this years.

It is, actually, really easy to use Isis domain models in other frameworks,
but we don't really explain how particularly well.  Hopefully the new site
will make it clearer that this is an option and have some better
information here.

I've been working on the online demo, and hope to have it hosted and
running in the next day or two.  It combines the HTML and JSON (REST)
viewers into a single WAR, so the user can switch between either view.  If
you're interested in a sneak peak, its in SVN at examples/onlinedemo.

Your idea of having a special JIRA list for would-be contributors to tackle
is a great one; I'll try to go through them and categorize them some how.
 Do you know how other Apache projects do this, by the way?

Thanks
Dan


On Monday, 28 November 2011, Bilgin Ibryam wrote:

> Hi Dan  and others,
>
> I think this is a really good start for some changes in ISIS.
> Coming from another Apache full-stack business app  oriented framework
> (Apache OFBiz) I find ISIS really interesting.
>
> Personally after reading the NO book and going through the examples, I
> found it hard to dive deeper into the framework, many viewers and
> deployment models... made it hard to focus on and understand the core
> functionality of the framework. So I strongly support the cleanup of
> the viewers and having in the base framework only the best (full and
> clean) implemented one as a reference.
>
> Another thing is that ISIS is a full-stack framework and not simply a
> tool which can be used as part of another project or development
> process, thus make it hard to use in real life projects.
>
> some other notes:
> I couldn't see a list(jira filter) for issues that can be fixed by
> newcomers.
> A running demo on Apache infrastucture would be good demonstration of
> ISIS features.
> I heard about ISIS on last year's LJC Open Conference. Giving a 5min
> lightening talk about ISIS on LJC gatherings would be helpful too.
>
> Cheers,
> Bilgin Ibryam
>
>
> On 21 November 2011 13:02, Dan Haywood <da...@haywood-associates.co.uk>
> wrote:
> > There's been an interesting thread going on in incubator@a.o [1] about
> (a)
> > the number of podlings in the incubator and (b) how long some of them are
> > taking to graduate.  One of the main points being made is that podlings
> that
> > have been in the incubator for a certain period of time (no-one is
> > suggesting how long exactly, but 1 year is being used as a strawman in
> the
> > thread) should be more explicit in defining their roadmap and action
> steps
> > towards graduation.
> >
> > To be honest, this is all very reasonable, but from Isis' point of view
> it
> > is perhaps slightly worrying, because although we've made some progress
> with
> > getting our code etc together (and the licenses, ICLAs, release processes
> > etc are in good shape), we haven't made a lot of progress in attracting
> new
> > committers.  Indeed, arguably we've gone backwards in that space: right
> now
> > only Kevin, Rob and myself currently actively commit.
> >
> > With that in mind, Kevin, Rob and I had a skype conf call this weekend to
> > discuss some ideas to move Isis forward towards graduation.  Obviously,
> this
> > is it's slightly against Apache policy ("if it didn't happen on the
> mailing
> > list then it didn't happen"), which is why I'm posting here now to post
> some
> > of our initial conclusions and to broaden out the discussion to everyone
> > else who might be interested.  (Kevin and Rob: correct me if I overstate
> on
> > any of this).
> >
> >
> > Marketing Message
> >
> > The main thing we discussed was the "marketing message" for Isis.
> >
> > Automatic UI
> >
> > The view we came to was that the automatic-UI generation part of Isis (ie
> > the naked objects pattern) is possibly more of a negative than a
> positive,
> > at least so far as attracting new users:
> > * That is, for those that have heard of naked objects (guestimate: 1/4 to
> > 1/3 of developers), chances are that they have dismissed it as being a
> way
> > to build over-simplified CRUD-style applications.  (Of course, those of
> us
> > who have actually used it to build apps know that ain't so, but that's a
> > different discussion).
> > * For those that have not heard of naked objects, the proposition that
> > "here's a framework that will automatically generate your UIs" doesn't
> > resonate.  Why? I guess we can speculate; my view is that there are now
> > plenty of UI technologies that are quite productive/easy to use/fun;
> > probably a lot more so than when the original naked objects framework was
> > developed c: 2000.  Another reason might be that developers put too much
> > emphasis over owning the UI rather than making sure the domain model is
> > good.
> >
> > On the other hand, we did conclude that the automatic-UI is useful as a
> > design tool, and would-be users of Isis could probably understand it in
> > those terms.  The fact that the automatic UI is also suitable for use by
> > end-users in some situations is subsidiary and something that adopters of
> > Isis might discover only later on.
> >
> > REST
> >
> > Another point that I was keen to see factored into the marketing message
> for
> > Isis is its REST support (the json-viewer).  As you may have picked up
> from
> > other posts, I've been developing a standalone spec, Restful Objects [2],
> > which defines defines a set of RESTful resources, and corresponding JSON
> > representations, for accessing and manipulating a domain object model.
> >
> > I'm quite excited by this Restful stuff.  On the one hand, as well as
> Isis'
> > implementation, there's also another .NET implementation underway via
> Naked
> > Objects MVC (Richard Pawson has been providing great feedback on the
> spec).
> > And Johan Andries has been making good progress on a new RESTful UI,
> which
> > I'm hoping might go open source.  Also, the REST approach has met a good
> > reaction at our (joint) client in Ireland.
> >
> > In terms of marketing, my view is that REST is an area where there is
> > currently a lot of interest, but developers looking into it will likely
> > realise that it's a complex area to do right (ful support for HATEOAS,
> HTTP
> > headers and status codes etc).  As such, developers might be interested
> in a
> > framework that can help them out, at a somewhat higher level of
> abstraction
> > than JSR-311.  The proposition is: press a button and get

Re: Thoughts on how to grow our community.

[Bilgin Ibryam <bi...@gmail.com>]

Hi Dan  and others,

I think this is a really good start for some changes in ISIS.
Coming from another Apache full-stack business app  oriented framework
(Apache OFBiz) I find ISIS really interesting.

Personally after reading the NO book and going through the examples, I
found it hard to dive deeper into the framework, many viewers and
deployment models... made it hard to focus on and understand the core
functionality of the framework. So I strongly support the cleanup of
the viewers and having in the base framework only the best (full and
clean) implemented one as a reference.

Another thing is that ISIS is a full-stack framework and not simply a
tool which can be used as part of another project or development
process, thus make it hard to use in real life projects.

some other notes:
I couldn't see a list(jira filter) for issues that can be fixed by newcomers.
A running demo on Apache infrastucture would be good demonstration of
ISIS features.
I heard about ISIS on last year's LJC Open Conference. Giving a 5min
lightening talk about ISIS on LJC gatherings would be helpful too.

Cheers,
Bilgin Ibryam


On 21 November 2011 13:02, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> There's been an interesting thread going on in incubator@a.o [1] about (a)
> the number of podlings in the incubator and (b) how long some of them are
> taking to graduate.  One of the main points being made is that podlings that
> have been in the incubator for a certain period of time (no-one is
> suggesting how long exactly, but 1 year is being used as a strawman in the
> thread) should be more explicit in defining their roadmap and action steps
> towards graduation.
>
> To be honest, this is all very reasonable, but from Isis' point of view it
> is perhaps slightly worrying, because although we've made some progress with
> getting our code etc together (and the licenses, ICLAs, release processes
> etc are in good shape), we haven't made a lot of progress in attracting new
> committers.  Indeed, arguably we've gone backwards in that space: right now
> only Kevin, Rob and myself currently actively commit.
>
> With that in mind, Kevin, Rob and I had a skype conf call this weekend to
> discuss some ideas to move Isis forward towards graduation.  Obviously, this
> is it's slightly against Apache policy ("if it didn't happen on the mailing
> list then it didn't happen"), which is why I'm posting here now to post some
> of our initial conclusions and to broaden out the discussion to everyone
> else who might be interested.  (Kevin and Rob: correct me if I overstate on
> any of this).
>
>
> Marketing Message
>
> The main thing we discussed was the "marketing message" for Isis.
>
> Automatic UI
>
> The view we came to was that the automatic-UI generation part of Isis (ie
> the naked objects pattern) is possibly more of a negative than a positive,
> at least so far as attracting new users:
> * That is, for those that have heard of naked objects (guestimate: 1/4 to
> 1/3 of developers), chances are that they have dismissed it as being a way
> to build over-simplified CRUD-style applications.  (Of course, those of us
> who have actually used it to build apps know that ain't so, but that's a
> different discussion).
> * For those that have not heard of naked objects, the proposition that
> "here's a framework that will automatically generate your UIs" doesn't
> resonate.  Why? I guess we can speculate; my view is that there are now
> plenty of UI technologies that are quite productive/easy to use/fun;
> probably a lot more so than when the original naked objects framework was
> developed c: 2000.  Another reason might be that developers put too much
> emphasis over owning the UI rather than making sure the domain model is
> good.
>
> On the other hand, we did conclude that the automatic-UI is useful as a
> design tool, and would-be users of Isis could probably understand it in
> those terms.  The fact that the automatic UI is also suitable for use by
> end-users in some situations is subsidiary and something that adopters of
> Isis might discover only later on.
>
> REST
>
> Another point that I was keen to see factored into the marketing message for
> Isis is its REST support (the json-viewer).  As you may have picked up from
> other posts, I've been developing a standalone spec, Restful Objects [2],
> which defines defines a set of RESTful resources, and corresponding JSON
> representations, for accessing and manipulating a domain object model.
>
> I'm quite excited by this Restful stuff.  On the one hand, as well as Isis'
> implementation, there's also another .NET implementation underway via Naked
> Objects MVC (Richard Pawson has been providing great feedback on the spec).
> And Johan Andries has been making good progress on a new RESTful UI, which
> I'm hoping might go open source.  Also, the REST approach has met a good
> reaction at our (joint) client in Ireland.
>
> In terms of marketing, my view is that REST is an area where there is
> currently a lot of interest, but developers looking into it will likely
> realise that it's a complex area to do right (ful support for HATEOAS, HTTP
> headers and status codes etc).  As such, developers might be interested in a
> framework that can help them out, at a somewhat higher level of abstraction
> than JSR-311.  The proposition is: press a button and get a complete, fully
> restful API to any domain model.
>
> DDD
>
> A third message is for those that are interested in domain modelling/domain
> driven design, for whom the automatic UI might (again) be a useful design
> tool who might want to deploy their app on some other framework, eg Spring
> or JEE.
>
> So, overall this gives us three target use cases to address.  The view we
> took on was that the home page should reflect these use cases:
> - domain modelling (and deploy on own platform)
> - REST
> - automatically generated webapp (primarily to support the other two use
> cases, but optionally as a deployment in its own right)
>
> With this in mind I've sketched up a new graphic that could be used for the
> home page, see [3].  The current home page (the hexagonal architecture)
> would probably be demoted to a supporting page describing the architecture
> of Isis.
>
> In addition, we thought that the side bar menu should be restructured around
> these use cases.
>
>
> Alpha status viewers
>
> Another point we discussed was the incomplete nature of some of the
> viewers.  Having would-be users come across code that is broken is clearly
> not a good experience, at least if there expectations are that everything
> works.
>
> Specifically:
> * the scimpi viewer is code complete but its supporting documentation is
> incomplete
> * the wicket viewer is not complete (though it's documentation is pretty
> good!)
> * the xhtml viewer (which is a precursor to the json viewer, but using XHTML
> representations) is superceded by the json viewer and so should be removed
> * the dnd viewer (which has worked in the past), is currently broken
> (doesn't repaint properly)
>
> We discussed the dnd viewer quite a lot.  Although it is, in some sense, the
> "purest" expression of the naked objects pattern (bringing in some of the
> original ideas of expressive systems), the truth, probably, is that for our
> target audience this isn't important to emphasise.  Crudely put: would-be
> users are not going to understand what the somewhat unconventionaly UI that
> the dnd browser provides is trying to achieve.  The fact that it is
> currently broken hardly helps atters.
>
> So one of the points we thought made sense was to change things so that the
> HTML viewer is the default, rather than DnD.
>
> In terms of the documentation and the site, we decided that the web site
> pages for the scimpi, wicket and dnd viewers should indicate that they are
> "alpha" status, and on the left hand menu we should group them under "other
> viewers".  As such, we probably should remove them from the Maven archetype
> until such time that they are back to production quality.
>
>
> Remoting
>
> We also discussed the remoting component.  The remoting component enables
> the dnd viewer to be deployed in a client/server configuration, and is what
> is used in the big Irish project (on the old .NET version of the naked
> objects framework).  However, my personal view is that remoting is, well,
> broken.  In fact, I think it should be removed: (a) the caching semantics
> for client-side domain objects is not well-defined; (b) anyone wanting a
> client/server solution would probably look towards an approach that uses
> REST, (c) the remoting support introduces a lot of complexity in the default
> runtime (notably, the separation of the "Persistor" API and the
> "ObjectStore" API).
>
> However, we didn't necessarily all agree on this viewpoint.  So for now, we
> decided to de-emphasise remoting, because it doesn't fit into the 3 main use
> cases that we highlighted above.  That means that it won't appear in the
> left-hand menu, for example.  My suggestion is that we link to it from the
> dnd viewer page (because that's the only viewer that would make use of it).
>
>
> Release
>
> Kevin has been working through the release procedures that I documented, and
> made some changes and clarifications.  I think that by-and-large they are
> holding up ok.
>
> I offered to push out a new release, because we are well overdue for another
> release.   I propose to do this once we've restructured the site a little
> (assuming that we go with the ideas I'm summarizing in this thread).
>
>
> Blogging
>
> In terms of building up a community, I suggested that we need to be more
> organized about blogging.  A little organization here between the
> contributors could substantially increase Isis' reach:
>
> * one idea is that Rob, Kevin and I take it in turns to publish a blog post
> such that there is at least one new blog post every week
> * blog posts should also be cross posted to blogs.apache.org (which will hit
> some other aggregators)
> * publicise blog posts in twitter using #apache #isis hashtags
> * publicise blog posts via dzone.com (and any other places you might choose)
> * publicise blog posts via isis-dev mailing list, and ask others to up-vote
> in dzone).
>
> In terms of content, one question raised was what, exactly, to blog about.
> My thoughts are:
> * choose a theme for a series of blogs:
>    - eg tips-n-tricks taken from applications working on (Robert's
> PlanChaser, or Kevin's various apps)
>    - copy-n-paste some of the sidebars from the Richard/Robert's original
> Naked Objects book (for Robert)
>    - work through some of the applib conventions, eg how to do choices for a
> property.
>
> In terms of "how to":
> * keep it short, something that won't take more than 2 or 3 minutes to read
> * if you have more than that, then leave it to the next part
> * sit down and write 2 or 3 posts at a time (or split up a draft blog post
> that's got too long) and then only publish them according to a schedule
>
>
> Articles
>
> Rob, Kevin and I didn't discuss writing articles in our call; clearly some
> articles would be good (eg infoq.com or theserverside.com), but it takes
> that much more time to do.  I'd rather focus on just getting a steady stream
> of blog posts going first.
>
>
> Thoughts?
>
> OK, I think that more or less summarises the points that I wanted to raise.
> If anyone has any views on this/clarifications/corrections, then post them
> here.
>
> Meantime, I intend to put some additional material on blogging up onto our
> wiki.
>
>
> Thanks,
> Dan
>
> [1] http://osdir.com/ml/general.incubator.apache.org/2011-11/msg00182.html
> [2] http://restfulobjects.org/
> [3] https://cwiki.apache.org/confluence/display/ISIS/RevampedSiteIdeas

Re: Thoughts on how to grow our community.

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

Since Cayenne integrates with the domain objects, I was wondering if 
it could be supported by providing an alternate 
AbstractDomainController that exposes the basic functionality.  

I need to contact someone in the Cayenne community about how to 
set it up programmatically, without using the design console, etc.

But thanks for the heads-up. Option (2) sounds the best - I definitely 
*don't* think (at the moment) that writing a new object store is the way 
to go. (But I *am* familiar with the ObjectStore API, as I've just finished 
my cludgy REST implementation for integrating with Community 
Builder on Joomla!). Need to blog about that, too, I suppose!

On 1 Dec 2011 at 9:14, Dan Haywood wrote:

> Hi Kevin,
> I've not used Cayenne, no.  I don't notice it much in the news either (but
> that's not a criticism - it's not like Isis gets much coverage either).
> 
> If you're interested in working on a Cayenne integration, then there are
> two options.
> 
> 1. you could write a new object store, like the SQL object store that you
> took over.
> 
> 2. you could instead write a new runtime.
> 
> We haven't talked much about (2), but you'll know that I restructured the
> modules last year in order to give us oai.runtimes.dflt as well as
> oai.runtimes.embedded.  The key interface here
> is oai.core.metamodel.runtimecontext.RuntimeContext, which is the
> "pipeline" through which the metamodel API reaches back to the runtime.
> 
> You'll see that there are just two proper impls of this interface,
> the org.apache.isis.runtimes.dflt.runtime.persistence.internal.RuntimeContextFromSession
> which delegates to the (singleton) IsisContext in the dflt runtime, and
> there's also
> the oai.runtimes.embedded.internal.RuntimeContextForEmbeddedMetaModel,
> which is the capability I put together (though haven't properly advertised
> or promoted) to allow the Isis metamodel to be embedded in *any* other
> framework.
> 
> At any rate, what you might want to do is consider writing an
> oai.runtimes.cayenne.RuntimeContextForCayenne impl.  It'd be interesting to
> see how well this API works for a new requirement.
> 
> Just a thought,
> 
> Cheers
> Dan

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi Kevin,
I've not used Cayenne, no.  I don't notice it much in the news either (but
that's not a criticism - it's not like Isis gets much coverage either).

If you're interested in working on a Cayenne integration, then there are
two options.

1. you could write a new object store, like the SQL object store that you
took over.

2. you could instead write a new runtime.

We haven't talked much about (2), but you'll know that I restructured the
modules last year in order to give us oai.runtimes.dflt as well as
oai.runtimes.embedded.  The key interface here
is oai.core.metamodel.runtimecontext.RuntimeContext, which is the
"pipeline" through which the metamodel API reaches back to the runtime.

You'll see that there are just two proper impls of this interface,
the org.apache.isis.runtimes.dflt.runtime.persistence.internal.RuntimeContextFromSession
which delegates to the (singleton) IsisContext in the dflt runtime, and
there's also
the oai.runtimes.embedded.internal.RuntimeContextForEmbeddedMetaModel,
which is the capability I put together (though haven't properly advertised
or promoted) to allow the Isis metamodel to be embedded in *any* other
framework.

At any rate, what you might want to do is consider writing an
oai.runtimes.cayenne.RuntimeContextForCayenne impl.  It'd be interesting to
see how well this API works for a new requirement.

Just a thought,

Cheers
Dan

PS: We have a JIRA that was raised a while back (ISIS-14) for Isis to
provide support for JDO.  When, one day - haha - we get around to tackling
this, my thought was that it should use the RuntimeContext API.  After all,
since JDO abstracts a ton of persistence APIs, I can't see the point on
layering our dflt runtime on top of it.



On Wednesday, 23 November 2011, Kevin Meyer - KMZ wrote:

> I'm just going to focus on the bits that are close to my heart (I don't
> have any issues with the rest, though)... continued below...
>
> On 23 Nov 2011 at 17:26, Dan Haywood wrote:
>
> > ~~~
> > Alexander's slightly tongue-in-cheek question is funny, cos actually
> > long-term I do think that Isis should lose its persistence layer.  My
> view
> > is that the fact that it can only be deployed on the handful of
> > objectstores that we have implementations for counts against it.  In
> time I
> > would like to simplify the whole, rather complex, runtime/back-end, and
> > plug into JDO or JPA or maybe have a really lightweight implementations
> > around NoSQL (eg Mongo).
>
> I just read a little about Cayenne[1]. Has anyone used it?
>
> I am particularly anti any DAL that *requires* additional annotations or
> XML files or other extra bits to support persistence. I resent Hibernate,
> OpenXava, etc.
>
> As it stands, the Isis SQL/JDBC objectstore works (but is perhaps not
> suited for large scale production use - let me know if you've tried and
> failed). And it works automatically, as far as the domain developer is
> concerned. It even supports polymorphic domain objects. (Yes, yes, it
> could do with some improvements.. I have some ideas, already).
>
> I am happy for the Isis Persistence API / Objectstore API to be
> simplified (can't actually say I really noticed the split, myself), and I
> do
> see advantages to making some Objectstore functionality more
> apparent (accessible) to the domain (e.g. pagination, custom queries).
>
> But, having said that, I would like to see how is it possible to integrate
> with other store technologies (JDO/Cayenne/etc) - but, to me, it must
> be seamless - only requiring "something extra" when you're trying to
> do something special (What special? To be determined).
>
> Regards,
> Kevin
>
> [1] http://cayenne.apache.org/
>

Re: Thoughts on how to grow our community.

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

I'm just going to focus on the bits that are close to my heart (I don't 
have any issues with the rest, though)... continued below...

On 23 Nov 2011 at 17:26, Dan Haywood wrote:

> ~~~
> Alexander's slightly tongue-in-cheek question is funny, cos actually
> long-term I do think that Isis should lose its persistence layer.  My view
> is that the fact that it can only be deployed on the handful of
> objectstores that we have implementations for counts against it.  In time I
> would like to simplify the whole, rather complex, runtime/back-end, and
> plug into JDO or JPA or maybe have a really lightweight implementations
> around NoSQL (eg Mongo).

I just read a little about Cayenne[1]. Has anyone used it?

I am particularly anti any DAL that *requires* additional annotations or 
XML files or other extra bits to support persistence. I resent Hibernate, 
OpenXava, etc.

As it stands, the Isis SQL/JDBC objectstore works (but is perhaps not 
suited for large scale production use - let me know if you've tried and 
failed). And it works automatically, as far as the domain developer is 
concerned. It even supports polymorphic domain objects. (Yes, yes, it 
could do with some improvements.. I have some ideas, already).

I am happy for the Isis Persistence API / Objectstore API to be 
simplified (can't actually say I really noticed the split, myself), and I do 
see advantages to making some Objectstore functionality more 
apparent (accessible) to the domain (e.g. pagination, custom queries).

But, having said that, I would like to see how is it possible to integrate 
with other store technologies (JDO/Cayenne/etc) - but, to me, it must 
be seamless - only requiring "something extra" when you're trying to 
do something special (What special? To be determined).

Regards,
Kevin

[1] http://cayenne.apache.org/

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

I'm glad this thread has started some discussion; it's good to get some
"soundings".

To be clear: the proposal isn't about removing NO or autogenerated UIs,
though it is about making sure that code that is incomplete is clearly
marked as such so that would-be users don't try something out, find it
doesn't work properly, and then walk away.

However, we do want to find a way to make the use cases that we support
more explicit.

What I hear is that the auto-generated UI is important to this community;
it's used by (I imagine) all of us for prototyping, and it's used by some
of us for deployment into production.

That said, I'm also pretty sure that many would-be developers *don't* see
an automatically generated UI as being something they care about.  Or, they
may have negative preconceptions about the NO pattern.  So for these people
we should make it much more obvious that Isis' is also a great platform for
REST.

The other point that I'm hearing is we need to make it easy for would-be
developers to verify our claims for themselves, hence the demo apps etc.
 Fully agreed on that.  As you might have seen, Mike Burton is donating
some server capacity for us, and I'm gonna work on that area.  (Thanks,
Mike!)

~~~
Alexander's slightly tongue-in-cheek question is funny, cos actually
long-term I do think that Isis should lose its persistence layer.  My view
is that the fact that it can only be deployed on the handful of
objectstores that we have implementations for counts against it.  In time I
would like to simplify the whole, rather complex, runtime/back-end, and
plug into JDO or JPA or maybe have a really lightweight implementations
around NoSQL (eg Mongo).

Thus, Isis is (and will always be):
(a) an extensible metamodel, predicated on the idea of behaviourally
complete objects
(b) it provides an abstraction over the domain object instances in some
"runtime"
(c) viewers of the domain object with respect to that metamodel.

And of the viewers, there's a whole spectrum, of various customizability,
but I think that the REST one deserves special prominence w.r.t finding a
new audience, and the HTML viewer deserves special mention cos its
currently the one that's the most robust.  The others we de-emphasise until
they have the additional work put into them to make it clear which use
cases they target.

Further thoughts/discussion very welcome.

Cheers
Dan




On 23 November 2011 17:00, Alexander Krasnukhin <th...@gmail.com>wrote:

> You can remove persistent layer next and NO will magically disappear.
>
> On Wed, Nov 23, 2011 at 5:38 PM, Johan Andries <johan.andries@gmail.com
> >wrote:
>
> > Oh. The *current* home page puts the n.o. pattern and the hexagonal
> > architecture forward as the foundation of Apache Isis, but then again,
> > that home page is about to be redesigned.
> >
> > But if you remove the n.o. focus, then what is left? Isn't Grails a
> > better option if you do want to write a custom UI for everything (and
> > keep it up to date all the time)? I guess I'm confused.
> >
> > Johan.
> >
> > On Wed, Nov 23, 2011 at 3:01 PM, Luis Bender
> > <lu...@processmind.com.br> wrote:
> > > Agreed, Johan.
> > >
> > > My perception may be wrong, but from the previous messages it seems
> that
> > > we're close to giving up the OOUI (and the NO pattern) instead of
> > improving
> > > it.
> > >
> > > Cheers,
> > >  - Bender
> >
>
>
>
> --
> Regards,
> Alexander
>

Re: Thoughts on how to grow our community.

[Alexander Krasnukhin <th...@gmail.com>]

You can remove persistent layer next and NO will magically disappear.

On Wed, Nov 23, 2011 at 5:38 PM, Johan Andries <jo...@gmail.com>wrote:

> Oh. The *current* home page puts the n.o. pattern and the hexagonal
> architecture forward as the foundation of Apache Isis, but then again,
> that home page is about to be redesigned.
>
> But if you remove the n.o. focus, then what is left? Isn't Grails a
> better option if you do want to write a custom UI for everything (and
> keep it up to date all the time)? I guess I'm confused.
>
> Johan.
>
> On Wed, Nov 23, 2011 at 3:01 PM, Luis Bender
> <lu...@processmind.com.br> wrote:
> > Agreed, Johan.
> >
> > My perception may be wrong, but from the previous messages it seems that
> > we're close to giving up the OOUI (and the NO pattern) instead of
> improving
> > it.
> >
> > Cheers,
> >  - Bender
>



-- 
Regards,
Alexander

Re: Thoughts on how to grow our community.

[Luis Bender <lu...@processmind.com.br>]

Don't get me wrong, I'm all for improving and taking OOUI to the next
level, not getting rid of it. Just felt we were going in that direction.

 - Bender

2011/11/23 Johan Andries <jo...@gmail.com>

> Oh. The *current* home page puts the n.o. pattern and the hexagonal
> architecture forward as the foundation of Apache Isis, but then again,
> that home page is about to be redesigned.
>
> But if you remove the n.o. focus, then what is left? Isn't Grails a
> better option if you do want to write a custom UI for everything (and
> keep it up to date all the time)? I guess I'm confused.
>
> Johan.
>
> On Wed, Nov 23, 2011 at 3:01 PM, Luis Bender
> <lu...@processmind.com.br> wrote:
> > Agreed, Johan.
> >
> > My perception may be wrong, but from the previous messages it seems that
> > we're close to giving up the OOUI (and the NO pattern) instead of
> improving
> > it.
> >
> > Cheers,
> >  - Bender
>

Re: Thoughts on how to grow our community.

[Johan Andries <jo...@gmail.com>]

Oh. The *current* home page puts the n.o. pattern and the hexagonal
architecture forward as the foundation of Apache Isis, but then again,
that home page is about to be redesigned.

But if you remove the n.o. focus, then what is left? Isn't Grails a
better option if you do want to write a custom UI for everything (and
keep it up to date all the time)? I guess I'm confused.

Johan.

On Wed, Nov 23, 2011 at 3:01 PM, Luis Bender
<lu...@processmind.com.br> wrote:
> Agreed, Johan.
>
> My perception may be wrong, but from the previous messages it seems that
> we're close to giving up the OOUI (and the NO pattern) instead of improving
> it.
>
> Cheers,
>  - Bender

Re: Thoughts on how to grow our community.

[Luis Bender <lu...@processmind.com.br>]

Agreed, Johan.

My perception may be wrong, but from the previous messages it seems that
we're close to giving up the OOUI (and the NO pattern) instead of improving
it.

Cheers,
 - Bender

2011/11/23 Johan Andries <jo...@gmail.com>

> On Tue, Nov 22, 2011 at 7:33 PM, Mike Burton <mi...@mycosystems.co.uk>
> wrote:
> > Hi Dan,
> >
> >>Marketing message
> > I think Isis' real strength is prototyping the domain model, the auto-UI
> is more important as an enabler for this than as a general UI generator.
>
> I would not underestimate the value of the auto UI generation or more
> generally the naked objects pattern. I guess a typical project team
> spends 65% of the effort on the UI (model/view/controller) and the
> service layer around the (anemic) domain objects. There are many IT
> organisations that are getting slowed down more and more by a huge
> legacy code base (be it Cobol, RPG or Oracle Forms with lots of
> PL/SQL) and replacing this old stuff (either gradually or in a big
> bang scenario) is a risky and costly thing for a CIO.
>
> Now the UI generated by Isis will be a little bit unusual, but so are
> the UIs on mainframes or Oracle Forms. At least with Apache Isis you
> have the possibility to replace the auto-generated UI step-by-step
> where it hurts the most. A fraction of the time you gain by the
> automated UIs can be invested in decent domain modeling, which in turn
> will pay off in the long run.
>
> Johan.
>

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

These are good words, Johan; I'll try to factor them into the revamped Isis
site.

Thx
Dan


On Wednesday, 23 November 2011, Johan Andries wrote:

> On Tue, Nov 22, 2011 at 7:33 PM, Mike Burton <mikeb@mycosystems.co.uk<javascript:;>>
> wrote:
> > Hi Dan,
> >
> >>Marketing message
> > I think Isis' real strength is prototyping the domain model, the auto-UI
> is more important as an enabler for this than as a general UI generator.
>
> I would not underestimate the value of the auto UI generation or more
> generally the naked objects pattern. I guess a typical project team
> spends 65% of the effort on the UI (model/view/controller) and the
> service layer around the (anemic) domain objects. There are many IT
> organisations that are getting slowed down more and more by a huge
> legacy code base (be it Cobol, RPG or Oracle Forms with lots of
> PL/SQL) and replacing this old stuff (either gradually or in a big
> bang scenario) is a risky and costly thing for a CIO.
>
> Now the UI generated by Isis will be a little bit unusual, but so are
> the UIs on mainframes or Oracle Forms. At least with Apache Isis you
> have the possibility to replace the auto-generated UI step-by-step
> where it hurts the most. A fraction of the time you gain by the
> automated UIs can be invested in decent domain modeling, which in turn
> will pay off in the long run.
>
> Johan.
>

Re: Thoughts on how to grow our community.

[Johan Andries <jo...@gmail.com>]

On Tue, Nov 22, 2011 at 7:33 PM, Mike Burton <mi...@mycosystems.co.uk> wrote:
> Hi Dan,
>
>>Marketing message
> I think Isis' real strength is prototyping the domain model, the auto-UI is more important as an enabler for this than as a general UI generator.

I would not underestimate the value of the auto UI generation or more
generally the naked objects pattern. I guess a typical project team
spends 65% of the effort on the UI (model/view/controller) and the
service layer around the (anemic) domain objects. There are many IT
organisations that are getting slowed down more and more by a huge
legacy code base (be it Cobol, RPG or Oracle Forms with lots of
PL/SQL) and replacing this old stuff (either gradually or in a big
bang scenario) is a risky and costly thing for a CIO.

Now the UI generated by Isis will be a little bit unusual, but so are
the UIs on mainframes or Oracle Forms. At least with Apache Isis you
have the possibility to replace the auto-generated UI step-by-step
where it hurts the most. A fraction of the time you gain by the
automated UIs can be invested in decent domain modeling, which in turn
will pay off in the long run.

Johan.

Re: Thoughts on how to grow our community.

[Mike Burton <mi...@mycosystems.co.uk>]

Hi Dan,

>Marketing message
I think Isis' real strength is prototyping the domain model, the auto-UI is more important as an enabler for this than as a general UI generator.

>REST
I can definitely see the attraction of this, would be good to see examples of invoking it.

>VIEWERS
Agree. 
For me a quick "quick start" that works smoothly would have got me more involved in Isis, I guess that's the case for other developers too. 
The "Hosted Demo" idea would work well here too, especially if users could alter the domain classes and see the outcome. This would need to be in a safe / contrived way so as not to impact other users, or maybe a cron job to reset it every ?hour...

>REMOTING
I think REST has overtaken this.

>DDD / revamped site ideas  DIAGRAM
Maybe put more emphasis on the prototyping aspect of DDD.

Mike


On 21 Nov 2011, at 13:02, Dan Haywood wrote:

> There's been an interesting thread going on in incubator@a.o [1] about (a) the number of podlings in the incubator and (b) how long some of them are taking to graduate.  One of the main points being made is that podlings that have been in the incubator for a certain period of time (no-one is suggesting how long exactly, but 1 year is being used as a strawman in the thread) should be more explicit in defining their roadmap and action steps towards graduation.
> 
> To be honest, this is all very reasonable, but from Isis' point of view it is perhaps slightly worrying, because although we've made some progress with getting our code etc together (and the licenses, ICLAs, release processes etc are in good shape), we haven't made a lot of progress in attracting new committers.  Indeed, arguably we've gone backwards in that space: right now only Kevin, Rob and myself currently actively commit.
> 
> With that in mind, Kevin, Rob and I had a skype conf call this weekend to discuss some ideas to move Isis forward towards graduation.  Obviously, this is it's slightly against Apache policy ("if it didn't happen on the mailing list then it didn't happen"), which is why I'm posting here now to post some of our initial conclusions and to broaden out the discussion to everyone else who might be interested.  (Kevin and Rob: correct me if I overstate on any of this).
> 
> 
> Marketing Message
> 
> The main thing we discussed was the "marketing message" for Isis.
> 
> Automatic UI
> 
> The view we came to was that the automatic-UI generation part of Isis (ie the naked objects pattern) is possibly more of a negative than a positive, at least so far as attracting new users:
> * That is, for those that have heard of naked objects (guestimate: 1/4 to 1/3 of developers), chances are that they have dismissed it as being a way to build over-simplified CRUD-style applications.  (Of course, those of us who have actually used it to build apps know that ain't so, but that's a different discussion).
> * For those that have not heard of naked objects, the proposition that "here's a framework that will automatically generate your UIs" doesn't resonate.  Why? I guess we can speculate; my view is that there are now plenty of UI technologies that are quite productive/easy to use/fun; probably a lot more so than when the original naked objects framework was developed c: 2000.  Another reason might be that developers put too much emphasis over owning the UI rather than making sure the domain model is good.
> 
> On the other hand, we did conclude that the automatic-UI is useful as a design tool, and would-be users of Isis could probably understand it in those terms.  The fact that the automatic UI is also suitable for use by end-users in some situations is subsidiary and something that adopters of Isis might discover only later on.
> 
> REST
> 
> Another point that I was keen to see factored into the marketing message for Isis is its REST support (the json-viewer).  As you may have picked up from other posts, I've been developing a standalone spec, Restful Objects [2], which defines defines a set of RESTful resources, and corresponding JSON representations, for accessing and manipulating a domain object model.
> 
> I'm quite excited by this Restful stuff.  On the one hand, as well as Isis' implementation, there's also another .NET implementation underway via Naked Objects MVC (Richard Pawson has been providing great feedback on the spec).  And Johan Andries has been making good progress on a new RESTful UI, which I'm hoping might go open source.  Also, the REST approach has met a good reaction at our (joint) client in Ireland.
> 
> In terms of marketing, my view is that REST is an area where there is currently a lot of interest, but developers looking into it will likely realise that it's a complex area to do right (ful support for HATEOAS, HTTP headers and status codes etc).  As such, developers might be interested in a framework that can help them out, at a somewhat higher level of abstraction than JSR-311.  The proposition is: press a button and get a complete, fully restful API to any domain model.
> 
> DDD
> 
> A third message is for those that are interested in domain modelling/domain driven design, for whom the automatic UI might (again) be a useful design tool who might want to deploy their app on some other framework, eg Spring or JEE.
> 
> So, overall this gives us three target use cases to address.  The view we took on was that the home page should reflect these use cases:
> - domain modelling (and deploy on own platform)
> - REST
> - automatically generated webapp (primarily to support the other two use cases, but optionally as a deployment in its own right)
> 
> With this in mind I've sketched up a new graphic that could be used for the home page, see [3].  The current home page (the hexagonal architecture) would probably be demoted to a supporting page describing the architecture of Isis.
> 
> In addition, we thought that the side bar menu should be restructured around these use cases.
> 
> 
> Alpha status viewers
> 
> Another point we discussed was the incomplete nature of some of the viewers.  Having would-be users come across code that is broken is clearly not a good experience, at least if there expectations are that everything works.
> 
> Specifically:
> * the scimpi viewer is code complete but its supporting documentation is incomplete
> * the wicket viewer is not complete (though it's documentation is pretty good!)
> * the xhtml viewer (which is a precursor to the json viewer, but using XHTML representations) is superceded by the json viewer and so should be removed
> * the dnd viewer (which has worked in the past), is currently broken (doesn't repaint properly)
> 
> We discussed the dnd viewer quite a lot.  Although it is, in some sense, the "purest" expression of the naked objects pattern (bringing in some of the original ideas of expressive systems), the truth, probably, is that for our target audience this isn't important to emphasise.  Crudely put: would-be users are not going to understand what the somewhat unconventionaly UI that the dnd browser provides is trying to achieve.  The fact that it is currently broken hardly helps atters.
> 
> So one of the points we thought made sense was to change things so that the HTML viewer is the default, rather than DnD.  
> 
> In terms of the documentation and the site, we decided that the web site pages for the scimpi, wicket and dnd viewers should indicate that they are "alpha" status, and on the left hand menu we should group them under "other viewers".  As such, we probably should remove them from the Maven archetype until such time that they are back to production quality.
> 
> 
> Remoting
> 
> We also discussed the remoting component.  The remoting component enables the dnd viewer to be deployed in a client/server configuration, and is what is used in the big Irish project (on the old .NET version of the naked objects framework).  However, my personal view is that remoting is, well, broken.  In fact, I think it should be removed: (a) the caching semantics for client-side domain objects is not well-defined; (b) anyone wanting a client/server solution would probably look towards an approach that uses REST, (c) the remoting support introduces a lot of complexity in the default runtime (notably, the separation of the "Persistor" API and the "ObjectStore" API).
> 
> However, we didn't necessarily all agree on this viewpoint.  So for now, we decided to de-emphasise remoting, because it doesn't fit into the 3 main use cases that we highlighted above.  That means that it won't appear in the left-hand menu, for example.  My suggestion is that we link to it from the dnd viewer page (because that's the only viewer that would make use of it).
> 
> 
> Release
> 
> Kevin has been working through the release procedures that I documented, and made some changes and clarifications.  I think that by-and-large they are holding up ok.  
> 
> I offered to push out a new release, because we are well overdue for another release.   I propose to do this once we've restructured the site a little (assuming that we go with the ideas I'm summarizing in this thread).
> 
> 
> Blogging
> 
> In terms of building up a community, I suggested that we need to be more organized about blogging.  A little organization here between the contributors could substantially increase Isis' reach:
> 
> * one idea is that Rob, Kevin and I take it in turns to publish a blog post such that there is at least one new blog post every week
> * blog posts should also be cross posted to blogs.apache.org (which will hit some other aggregators)
> * publicise blog posts in twitter using #apache #isis hashtags
> * publicise blog posts via dzone.com (and any other places you might choose)
> * publicise blog posts via isis-dev mailing list, and ask others to up-vote in dzone).
> 
> In terms of content, one question raised was what, exactly, to blog about.  My thoughts are:
> * choose a theme for a series of blogs:
>    - eg tips-n-tricks taken from applications working on (Robert's PlanChaser, or Kevin's various apps)
>    - copy-n-paste some of the sidebars from the Richard/Robert's original Naked Objects book (for Robert)
>    - work through some of the applib conventions, eg how to do choices for a property.
> 
> In terms of "how to":
> * keep it short, something that won't take more than 2 or 3 minutes to read
> * if you have more than that, then leave it to the next part
> * sit down and write 2 or 3 posts at a time (or split up a draft blog post that's got too long) and then only publish them according to a schedule
> 
> 
> Articles
> 
> Rob, Kevin and I didn't discuss writing articles in our call; clearly some articles would be good (eg infoq.com or theserverside.com), but it takes that much more time to do.  I'd rather focus on just getting a steady stream of blog posts going first.
> 
> 
> Thoughts?
> 
> OK, I think that more or less summarises the points that I wanted to raise.  If anyone has any views on this/clarifications/corrections, then post them here.
> 
> Meantime, I intend to put some additional material on blogging up onto our wiki.
> 
> 
> Thanks,
> Dan
> 
> [1] http://osdir.com/ml/general.incubator.apache.org/2011-11/msg00182.html
> [2] http://restfulobjects.org/
> [3] https://cwiki.apache.org/confluence/display/ISIS/RevampedSiteIdeas

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

On 12 December 2011 05:11, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:

>
> It occured to me last night that another possible solution to growing the
> Isis development community is by encouraging contributions in domain
> libraries and services..
>
> For example, I was looking for a domain service that could be used to
> create a PDF [2]. This doesn't require any (much?) knowledge of Isis.
>

That's a good idea, though I think it will need some supporting materials
on the website.  Probably the minimum we can get away with is a page on the
updated website.

I know that we do have a category for domain services in JIRA, but it's
probably a little bare.

Let me see if I can flesh out both.



>
> Likewise, Johan's work on the JScript viewer[3].. could we not
> consider that as (possibly) user-contributed? Encourage Johan to be a
> contributor.
>

Definitely hope that happens.  Johan, might you consider that?

On a slightly different topic [since this thread is about the commnity, not
code] Johan has open sourced his codebase, so even if he doesn't fancy
becoming a contributor, we could still adopt his codebase (the license he's
chosen, MIT, is very liberal).




>
>
>
> [1] http://isis.markmail.org/message/o5e4vame2vozrokp
> [2] http://isis.markmail.org/message/ofeiwtkq23ltyxio
> [3] http://isis.markmail.org/message/tcddcoyz6blyscsd
>

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

I updated this material last night, actually.  Was gonna put out a blog
post advertisig them on Friday.  But the updated versions are committed to
SVN if they are of interest.

Cheers
Dan


On 14 December 2011 15:31, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:

> Hi Jason,
>
> Following up on what Dan said - there is some material on the Isis
> website[1] that Dan put together for presenting Isis to a wider
> audience.
>
> Perhaps you'd consider going through the presentation with Dan and
> making a presentation as an Isis representative?
>
> You can add details of your own experiences...
>
> Regards,
> Kevin
>
> [1] http://incubator.apache.org/isis/
> http://incubator.apache.org/isis/presentations/IntroducingApacheIsis.pptx
> http://incubator.apache.org/isis/presentations/IntroducingApacheIsis.ppt
>
> http://incubator.apache.org/isis/presentations/IntroducingApacheIsis-notes.pdf
> etc
>
> On 13 Dec 2011 at 7:02, Dan Haywood wrote:
>
> > Hi Jason,
> > good to see you on the list.
> >
> > Attending this conference might be a step too far; it's a long distance
> to
> > operate at and a lot of time to invest in what may be a long shot.
> >
> > What would help Isis more is your continued interest.  Please stay
> involved
> > with Isis and try to use it to solve problems, eg prototyping some domain
> > models.  If it falls short, let us know and we'll aim to address those
> > shortcomings.  And if it provides a payback for you, then hopefully
> others
> > in around you will want to start using it.
> >
> > Cheers
> > Dan
> >
> >
> >
> > On 12 December 2011 15:18, Richardson, Jason - FSA, Kansas City, MO <
> >
> > > I am not sure how things work but every year the US Department of
> > > Agriculture, Farm Service Agency (FSA) has an IT fair, where they
> invite
> > > vendors into the building.   Maybe the ISIS community could send a
> > > representative.  I'm not sure how productive it would be though.
>  Another
> > > option is to talk with the FSA Enterprise Architects or the
> Architecture
> > > Office and provide a presentation on how ISIS could be used to decrease
> > > development time, provide stabilized UI's, and to create quick proof of
> > > concepts.
> > >
> > > For example, it took me about 8 months but I was able to get JIRA
> accepted
> > > into the FSA, and it is really taking off now.  The FSA has a lot of
> > > dedicated software specialists that are itching to use techniques that
> > > could enhance their productivity and provide more stabilized products.
>  It
> > > just takes some "work" to get a foothold.
> > >
> > >
> > > Jason Richardson
> > > National Payments Service (NPS) Technical Lead
> > > USDA/FSA/AFAO/SCADG
> > > (Administrative and Financial Applications Office)
> > > (Service Center Accounting & Debt Group)
> > >
> > >
> > >
> >
>
>
> --
> Kevin Meyer, PhD, Pr.Sci.Nat
> KMZ             P.O. Box 9822, Sharon Park, South Africa.
> Tel: +27 11 363 2001    Cell: +27 83 346 3045
>
>
>

Re: Thoughts on how to grow our community.

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

Hi Jason,

Following up on what Dan said - there is some material on the Isis 
website[1] that Dan put together for presenting Isis to a wider 
audience. 

Perhaps you'd consider going through the presentation with Dan and 
making a presentation as an Isis representative?

You can add details of your own experiences...

Regards,
Kevin

[1] http://incubator.apache.org/isis/
http://incubator.apache.org/isis/presentations/IntroducingApacheIsis.pptx
http://incubator.apache.org/isis/presentations/IntroducingApacheIsis.ppt
http://incubator.apache.org/isis/presentations/IntroducingApacheIsis-notes.pdf
etc

On 13 Dec 2011 at 7:02, Dan Haywood wrote:

> Hi Jason,
> good to see you on the list.
> 
> Attending this conference might be a step too far; it's a long distance to
> operate at and a lot of time to invest in what may be a long shot.
> 
> What would help Isis more is your continued interest.  Please stay involved
> with Isis and try to use it to solve problems, eg prototyping some domain
> models.  If it falls short, let us know and we'll aim to address those
> shortcomings.  And if it provides a payback for you, then hopefully others
> in around you will want to start using it.
> 
> Cheers
> Dan
> 
> 
> 
> On 12 December 2011 15:18, Richardson, Jason - FSA, Kansas City, MO <
> 
> > I am not sure how things work but every year the US Department of
> > Agriculture, Farm Service Agency (FSA) has an IT fair, where they invite
> > vendors into the building.   Maybe the ISIS community could send a
> > representative.  I'm not sure how productive it would be though.  Another
> > option is to talk with the FSA Enterprise Architects or the Architecture
> > Office and provide a presentation on how ISIS could be used to decrease
> > development time, provide stabilized UI's, and to create quick proof of
> > concepts.
> >
> > For example, it took me about 8 months but I was able to get JIRA accepted
> > into the FSA, and it is really taking off now.  The FSA has a lot of
> > dedicated software specialists that are itching to use techniques that
> > could enhance their productivity and provide more stabilized products.  It
> > just takes some "work" to get a foothold.
> >
> >
> > Jason Richardson
> > National Payments Service (NPS) Technical Lead
> > USDA/FSA/AFAO/SCADG
> > (Administrative and Financial Applications Office)
> > (Service Center Accounting & Debt Group)
> >
> >
> >
> 


--
Kevin Meyer, PhD, Pr.Sci.Nat
KMZ		P.O. Box 9822, Sharon Park, South Africa.
Tel: +27 11 363 2001	Cell: +27 83 346 3045

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi Jason,
good to see you on the list.

Attending this conference might be a step too far; it's a long distance to
operate at and a lot of time to invest in what may be a long shot.

What would help Isis more is your continued interest.  Please stay involved
with Isis and try to use it to solve problems, eg prototyping some domain
models.  If it falls short, let us know and we'll aim to address those
shortcomings.  And if it provides a payback for you, then hopefully others
in around you will want to start using it.

Cheers
Dan



On 12 December 2011 15:18, Richardson, Jason - FSA, Kansas City, MO <
jason.richardson@kcc.usda.gov> wrote:

> I am not sure how things work but every year the US Department of
> Agriculture, Farm Service Agency (FSA) has an IT fair, where they invite
> vendors into the building.   Maybe the ISIS community could send a
> representative.  I'm not sure how productive it would be though.  Another
> option is to talk with the FSA Enterprise Architects or the Architecture
> Office and provide a presentation on how ISIS could be used to decrease
> development time, provide stabilized UI's, and to create quick proof of
> concepts.
>
> For example, it took me about 8 months but I was able to get JIRA accepted
> into the FSA, and it is really taking off now.  The FSA has a lot of
> dedicated software specialists that are itching to use techniques that
> could enhance their productivity and provide more stabilized products.  It
> just takes some "work" to get a foothold.
>
>
> Jason Richardson
> National Payments Service (NPS) Technical Lead
> USDA/FSA/AFAO/SCADG
> (Administrative and Financial Applications Office)
> (Service Center Accounting & Debt Group)
>
>
>

RE: Thoughts on how to grow our community.

["Richardson, Jason - FSA, Kansas City, MO" <ja...@kcc.usda.gov>]

I am not sure how things work but every year the US Department of Agriculture, Farm Service Agency (FSA) has an IT fair, where they invite vendors into the building.   Maybe the ISIS community could send a representative.  I'm not sure how productive it would be though.  Another option is to talk with the FSA Enterprise Architects or the Architecture Office and provide a presentation on how ISIS could be used to decrease development time, provide stabilized UI's, and to create quick proof of concepts.

For example, it took me about 8 months but I was able to get JIRA accepted into the FSA, and it is really taking off now.  The FSA has a lot of dedicated software specialists that are itching to use techniques that could enhance their productivity and provide more stabilized products.  It just takes some "work" to get a foothold.


Jason Richardson
National Payments Service (NPS) Technical Lead
USDA/FSA/AFAO/SCADG
(Administrative and Financial Applications Office)
(Service Center Accounting & Debt Group)


-----Original Message-----
From: Kevin Meyer - KMZ [mailto:kevin@kmz.co.za] 
Sent: Sunday, December 11, 2011 11:19 PM
To: isis-dev@incubator.apache.org
Subject: Re: Thoughts on how to grow our community.

Of course, I meant Benson, in [1], not Mark.

On 12 Dec 2011 at 7:11, Kevin Meyer - KMZ wrote:

> I'm raising this thread again.. and also in response to Mark's 
> message[1].
> 
> It occured to me last night that another possible solution to growing the 
> Isis development community is by encouraging contributions in domain 
> libraries and services..
> 
> For example, I was looking for a domain service that could be used to 
> create a PDF [2]. This doesn't require any (much?) knowledge of Isis.
> 
> Likewise, Johan's work on the JScript viewer[3].. could we not 
> consider that as (possibly) user-contributed? Encourage Johan to be a 
> contributor.
> 
> 
> 
> [1] http://isis.markmail.org/message/o5e4vame2vozrokp
> [2] http://isis.markmail.org/message/ofeiwtkq23ltyxio
> [3] http://isis.markmail.org/message/tcddcoyz6blyscsd

Re: Thoughts on how to grow our community.

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

Of course, I meant Benson, in [1], not Mark.

On 12 Dec 2011 at 7:11, Kevin Meyer - KMZ wrote:

> I'm raising this thread again.. and also in response to Mark's 
> message[1].
> 
> It occured to me last night that another possible solution to growing the 
> Isis development community is by encouraging contributions in domain 
> libraries and services..
> 
> For example, I was looking for a domain service that could be used to 
> create a PDF [2]. This doesn't require any (much?) knowledge of Isis.
> 
> Likewise, Johan's work on the JScript viewer[3].. could we not 
> consider that as (possibly) user-contributed? Encourage Johan to be a 
> contributor.
> 
> 
> 
> [1] http://isis.markmail.org/message/o5e4vame2vozrokp
> [2] http://isis.markmail.org/message/ofeiwtkq23ltyxio
> [3] http://isis.markmail.org/message/tcddcoyz6blyscsd

Re: Thoughts on how to grow our community.

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

I'm raising this thread again.. and also in response to Mark's 
message[1].

It occured to me last night that another possible solution to growing the 
Isis development community is by encouraging contributions in domain 
libraries and services..

For example, I was looking for a domain service that could be used to 
create a PDF [2]. This doesn't require any (much?) knowledge of Isis.

Likewise, Johan's work on the JScript viewer[3].. could we not 
consider that as (possibly) user-contributed? Encourage Johan to be a 
contributor.



[1] http://isis.markmail.org/message/o5e4vame2vozrokp
[2] http://isis.markmail.org/message/ofeiwtkq23ltyxio
[3] http://isis.markmail.org/message/tcddcoyz6blyscsd

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

Hi Johan,

Thanks for open sourcing this.

You didn't mention the license you chose, though I think (when I browsed to
your site there a few days ago) that it's compatible with Apache.  If
that's the case, it'd be quite good to bundle your browser in the online
demo that I've just uploaded (as per other thread, to
http://restfulobjects.org/demos).  However, it will need enhancing to set
the "isis.user" HTTP header which acts as the very basic authentication
mechanism that I've concocted.

Could you perhaps take a look at this?

Cheers




On Tuesday, 22 November 2011, Johan Andries wrote:

> Hi,
>
> my javascript proof-of-concept on top of the json-viewer is now
> officially open source: http://code.google.com/p/restfulobjects-js/
>
> Johan.
>
>
>

Re: Thoughts on how to grow our community.

[Johan Andries <jo...@gmail.com>]

Hi,

my javascript proof-of-concept on top of the json-viewer is now
officially open source: http://code.google.com/p/restfulobjects-js/

Johan.

On Mon, Nov 21, 2011 at 2:02 PM, Dan Haywood
<da...@haywood-associates.co.uk> wrote:
> REST
>
> Another point that I was keen to see factored into the marketing message for
> Isis is its REST support (the json-viewer).  As you may have picked up from
> other posts, I've been developing a standalone spec, Restful Objects [2],
> which defines defines a set of RESTful resources, and corresponding JSON
> representations, for accessing and manipulating a domain object model.
>
> I'm quite excited by this Restful stuff.  On the one hand, as well as Isis'
> implementation, there's also another .NET implementation underway via Naked
> Objects MVC (Richard Pawson has been providing great feedback on the spec).
> And Johan Andries has been making good progress on a new RESTful UI, which
> I'm hoping might go open source.  Also, the REST approach has met a good
> reaction at our (joint) client in Ireland.
>
> In terms of marketing, my view is that REST is an area where there is
> currently a lot of interest, but developers looking into it will likely
> realise that it's a complex area to do right (ful support for HATEOAS, HTTP
> headers and status codes etc).  As such, developers might be interested in a
> framework that can help them out, at a somewhat higher level of abstraction
> than JSR-311.  The proposition is: press a button and get a complete, fully
> restful API to any domain model.
>

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

On Wednesday, 23 November 2011, Luis Bender wrote:

> Hi Dan,
>
> Regarding the quick start, yes, you got the point. Starting from the Home<http://incubator.apache.org/isis/>page, if you want to quick start, you end up following a link to the Where
> to Start? <http://incubator.apache.org/isis/where-to-start.html> page,
> which starts with a Maven command line. If the target audience is the
> average developer, I think we should start with the environment setup and
> so on, like the "Naked Objects in About Five Minutes" from your book. Makes
> sense?
>
> Make sense.  I'll have to go and look at that chapter again ;-)

The "in about 5 minutes" tag is a good way of explaining to the casual
browser how much commitment we're asking from them upfront, so I think I'll
try to include that also in the words somewhere.




> Regarding the cool apps, choosing the right "domain" is important, I mean
> dealing with a domain that makes sense for everyone and perhaps the
> developer could easily change for his own use, like CRM, sales pipeline,
> service desk, etc.
>

So, for now, I've chosen a really simple domain - and probably too simple -
that of a task manager.  But then again, I think that having a really
complex domain makes it hard for the developer to unpick what's going on.
 I chose the todo list app mostly because I've been playing around with
todo list manager apps on my Android phone, and was thinking about what
information is needed on the backend to write a similar app using jqMobile.

As per other thread this morning, I've uploaded the online demo WAR to
http://restfulobjects.org/demos.  Hopefully there's enough there for now.
 The next iteration will also bundle a very simple jqMobile app as well.

In fact... for anyone reading this... why not have a go at writing a
similar app in your favorite (mobile or otherwise) UI toolkit, eg
SenchaTouch, jqTouch, Vaadin, GWT etc.

Cheers
Dan



>
> Cheers,
>  - Bender
>
> 2011/11/21 Dan Haywood <da...@haywood-associates.co.uk>
>
>  Thanks for this, Luis (I'm cc'ing my reply isis-dev, if that's ok).
>
> We do have a quick start, but from your mail I'm guessing you found it
> hidden away.  I think it makes sense to highlight this up on the home page
> more clearly.
>
> In terms of cool apps, do you have any thoughts?  (eg have you written one
> you'd like to donate?!)
>
> ~~~
> A related idea to engage people is to get our apps deployed as running
> demos.  If we're restricting them to just the REST viewer and HTML viewer,
> then I think that would be feasible.
>
> In terms of how to do this, one option might be to use Amazon EC2's
> Elastic Bean Stalk - which can be free for micro usage, I understand (
> http://aws.amazon.com/elasticbeanstalk/#pricing).  If someone fancied
> learning how to use this service...?
>
> Cheers
> Dan
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> On 21/11/2011 17:08, Luis Bender wrote:
>
> Dan,
>
> The first experience a developer gets from playing with the framework will
> very much determine if he will continue to evaluate the technology or try
> something else.
>
> So, I think we should maximize this first experience with a very easy
> step-by-step quick start and some very cool ready to run apps.
>
> Just my *2*¢.
>
> Regards,
>
> Luis Bender
> ProcessMind Business Process Applications
> +55 11 5505-3213 Office
> +55 11 8158-8820 Mobile
> Skype: luis.bender
>   <http://www.processmind.com.br/>
> website <http://www.processmind.com.br/> | blog<http://thebpmexperience.wordpress.com/>
>  | bpm forum <http://br.groups.yahoo.com/group/BPM-Forum/> | twitter<http://twitter.com/processmind>|
> jobone <http://www.jobone.com.br/>
>
>
>
>
> 2011/11/21 Dan Haywood <da...@haywood-associates.co.uk>
>
>  There's been an interesting thread going on in incubator@a.o [1] about
> (a) the number of podlings in the incubator and (b) how long some of them
> are taking to graduate.  One of the main points being made is that podlings
> that have been in the incubator for a certain period of time (no-one is
> suggesting how long exactly, but 1 year is being used as a strawman in the
> thread) should be more explicit in defining their roadmap and action steps
> towards graduation.
>
> To be honest, this is all very reasonable, but from Isis' point of view it
> is perhaps slightly worrying, because although we've made some progress
> with getting our code etc together (and the licenses, ICLAs, release
> processes etc are in good shape), we haven't made a lot of progress in
> attracting new committers.  Indeed, arguably we've gone backwards in that
> space: right now only Kevin, Rob and myself currently actively commit.
>
> With that in mind, Kevin, Rob and I had a skype conf call this weekend to
> discuss some ideas to move Isis forward towards graduation.  Obviously,
> this is it's slightly against Apache policy ("if it d
>
>

Re: Thoughts on how to grow our community.

[Luis Bender <lu...@processmind.com.br>]

Hi Dan,

Regarding the quick start, yes, you got the point. Starting from the
Home<http://incubator.apache.org/isis/>page, if you want to quick
start, you end up following a link to the Where
to Start? <http://incubator.apache.org/isis/where-to-start.html> page,
which starts with a Maven command line. If the target audience is the
average developer, I think we should start with the environment setup and
so on, like the "Naked Objects in About Five Minutes" from your book. Makes
sense?

Regarding the cool apps, choosing the right "domain" is important, I mean
dealing with a domain that makes sense for everyone and perhaps the
developer could easily change for his own use, like CRM, sales pipeline,
service desk, etc.

Cheers,
 - Bender

2011/11/21 Dan Haywood <da...@haywood-associates.co.uk>

>  Thanks for this, Luis (I'm cc'ing my reply isis-dev, if that's ok).
>
> We do have a quick start, but from your mail I'm guessing you found it
> hidden away.  I think it makes sense to highlight this up on the home page
> more clearly.
>
> In terms of cool apps, do you have any thoughts?  (eg have you written one
> you'd like to donate?!)
>
> ~~~
> A related idea to engage people is to get our apps deployed as running
> demos.  If we're restricting them to just the REST viewer and HTML viewer,
> then I think that would be feasible.
>
> In terms of how to do this, one option might be to use Amazon EC2's
> Elastic Bean Stalk - which can be free for micro usage, I understand (
> http://aws.amazon.com/elasticbeanstalk/#pricing).  If someone fancied
> learning how to use this service...?
>
> Cheers
> Dan
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> On 21/11/2011 17:08, Luis Bender wrote:
>
> Dan,
>
> The first experience a developer gets from playing with the framework will
> very much determine if he will continue to evaluate the technology or try
> something else.
>
> So, I think we should maximize this first experience with a very easy
> step-by-step quick start and some very cool ready to run apps.
>
> Just my *2*¢.
>
> Regards,
>
> Luis Bender
> ProcessMind Business Process Applications
> +55 11 5505-3213 Office
> +55 11 8158-8820 Mobile
> Skype: luis.bender
>   <http://www.processmind.com.br/>
> website <http://www.processmind.com.br/> | blog<http://thebpmexperience.wordpress.com/>
>  | bpm forum <http://br.groups.yahoo.com/group/BPM-Forum/> | twitter<http://twitter.com/processmind>|
> jobone <http://www.jobone.com.br/>
>
>
>
>
> 2011/11/21 Dan Haywood <da...@haywood-associates.co.uk>
>
>>  There's been an interesting thread going on in incubator@a.o [1] about
>> (a) the number of podlings in the incubator and (b) how long some of them
>> are taking to graduate.  One of the main points being made is that podlings
>> that have been in the incubator for a certain period of time (no-one is
>> suggesting how long exactly, but 1 year is being used as a strawman in the
>> thread) should be more explicit in defining their roadmap and action steps
>> towards graduation.
>>
>> To be honest, this is all very reasonable, but from Isis' point of view
>> it is perhaps slightly worrying, because although we've made some progress
>> with getting our code etc together (and the licenses, ICLAs, release
>> processes etc are in good shape), we haven't made a lot of progress in
>> attracting new committers.  Indeed, arguably we've gone backwards in that
>> space: right now only Kevin, Rob and myself currently actively commit.
>>
>> With that in mind, Kevin, Rob and I had a skype conf call this weekend to
>> discuss some ideas to move Isis forward towards graduation.  Obviously,
>> this is it's slightly against Apache policy ("if it didn't happen on the
>> mailing list then it didn't happen"), which is why I'm posting here now to
>> post some of our initial conclusions and to broaden out the discussion to
>> everyone else who might be interested.  (Kevin and Rob: correct me if I
>> overstate on any of this).
>>
>>
>> *Marketing Message*
>>
>> The main thing we discussed was the "marketing message" for Isis.
>>
>> *Automatic UI*
>>
>> The view we came to was that the automatic-UI generation part of Isis (ie
>> the naked objects pattern) is possibly more of a negative than a positive,
>> at least so far as attracting new users:
>> * That is, for those that have heard of naked objects (guestimate: 1/4 to
>> 1/3 of developers), chances are that they have dismissed it as being a way
>> to build over-simplified CRUD-style applications.  (Of course, those of us
>> who have actually used it to build apps know that ain't so, but that's a
>> different discussion).
>> * For those that have not heard of naked objects, the proposition that
>> "here's a framework that will automatically generate your UIs" doesn't
>> resonate.  Why? I guess we can speculate; my view is that there are now
>> plenty of UI technologies that are quite productive/easy to use/fun;
>> probably a lot more so than when the original naked objects framework was
>> developed c: 2000.  Another reason might be that developers put too much
>> emphasis over owning the UI rather than making sure the domain model is
>> good.
>>
>> On the other hand, we did conclude that the automatic-UI is useful as a
>> design tool, and would-be users of Isis could probably understand it in
>> those terms.  The fact that the automatic UI is also suitable for use by
>> end-users in some situations is subsidiary and something that adopters of
>> Isis might discover only later on.
>>
>> *REST*
>>
>> Another point that I was keen to see factored into the marketing message
>> for Isis is its REST support (the json-viewer).  As you may have picked up
>> from other posts, I've been developing a standalone spec, Restful Objects
>> [2], which defines defines a set of RESTful resources, and corresponding
>> JSON representations, for accessing and manipulating a domain object model.
>>
>> I'm quite excited by this Restful stuff.  On the one hand, as well as
>> Isis' implementation, there's also another .NET implementation underway via
>> Naked Objects MVC (Richard Pawson has been providing great feedback on the
>> spec).  And Johan Andries has been making good progress on a new RESTful
>> UI, which I'm hoping might go open source.  Also, the REST approach has met
>> a good reaction at our (joint) client in Ireland.
>>
>> In terms of marketing, my view is that REST is an area where there is
>> currently a lot of interest, but developers looking into it will likely
>> realise that it's a complex area to do right (ful support for HATEOAS, HTTP
>> headers and status codes etc).  As such, developers might be interested in
>> a framework that can help them out, at a somewhat higher level of
>> abstraction than JSR-311.  The proposition is: press a button and get a
>> complete, fully restful API to any domain model.
>>
>> *DDD*
>>
>> A third message is for those that are interested in domain
>> modelling/domain driven design, for whom the automatic UI might (again) be
>> a useful design tool who might want to deploy their app on some other
>> framework, eg Spring or JEE.
>>
>> So, overall this gives us three target use cases to address.  The view we
>> took on was that the home page should reflect these use cases:
>> - domain modelling (and deploy on own platform)
>> - REST
>> - automatically generated webapp (primarily to support the other two use
>> cases, but optionally as a deployment in its own right)
>>
>> With this in mind I've sketched up a new graphic that could be used for
>> the home page, see [3].  The current home page (the hexagonal architecture)
>> would probably be demoted to a supporting page describing the architecture
>> of Isis.
>>
>> In addition, we thought that the side bar menu should be restructured
>> around these use cases.
>>
>>
>> *Alpha status viewers*
>>
>> Another point we discussed was the incomplete nature of some of the
>> viewers.  Having would-be users come across code that is broken is clearly
>> not a good experience, at least if there expectations are that everything
>> works.
>>
>> Specifically:
>> * the scimpi viewer is code complete but its supporting documentation is
>> incomplete
>> * the wicket viewer is not complete (though it's documentation is pretty
>> good!)
>> * the xhtml viewer (which is a precursor to the json viewer, but using
>> XHTML representations) is superceded by the json viewer and so should be
>> removed
>> * the dnd viewer (which has worked in the past), is currently broken
>> (doesn't repaint properly)
>>
>> We discussed the dnd viewer quite a lot.  Although it is, in some sense,
>> the "purest" expression of the naked objects pattern (bringing in some of
>> the original ideas of expressive systems), the truth, probably, is that for
>> our target audience this isn't important to emphasise.  Crudely put:
>> would-be users are not going to understand what the somewhat
>> unconventionaly UI that the dnd browser provides is trying to achieve.  The
>> fact that it is currently broken hardly helps atters.
>>
>> So one of the points we thought made sense was to change things so that
>> the HTML viewer is the default, rather than DnD.
>>
>> In terms of the documentation and the site, we decided that the web site
>> pages for the scimpi, wicket and dnd viewers should indicate that they are
>> "alpha" status, and on the left hand menu we should group them under "other
>> viewers".  As such, we probably should remove them from the Maven archetype
>> until such time that they are back to production quality.
>>
>>
>> *Remoting*
>>
>> We also discussed the remoting component.  The remoting component enables
>> the dnd viewer to be deployed in a client/server configuration, and is what
>> is used in the big Irish project (on the old .NET version of the naked
>> objects framework).  However, my personal view is that remoting is, well,
>> broken.  In fact, I think it should be removed: (a) the caching semantics
>> for client-side domain objects is not well-defined; (b) anyone wanting a
>> client/server solution would probably look towards an approach that uses
>> REST, (c) the remoting support introduces a lot of complexity in the
>> default runtime (notably, the separation of the "Persistor" API and the
>> "ObjectStore" API).
>>
>> However, we didn't necessarily all agree on this viewpoint.  So for now,
>> we decided to de-emphasise remoting, because it doesn't fit into the 3 main
>> use cases that we highlighted above.  That means that it won't appear in
>> the left-hand menu, for example.  My suggestion is that we link to it from
>> the dnd viewer page (because that's the only viewer that would make use of
>> it).
>>
>>
>> *Release*
>>
>> Kevin has been working through the release procedures that I documented,
>> and made some changes and clarifications.  I think that by-and-large they
>> are holding up ok.
>>
>> I offered to push out a new release, because we are well overdue for
>> another release.   I propose to do this once we've restructured the site a
>> little (assuming that we go with the ideas I'm summarizing in this thread).
>>
>>
>> *Blogging*
>>
>> In terms of building up a community, I suggested that we need to be more
>> organized about blogging.  A little organization here between the
>> contributors could substantially increase Isis' reach:
>>
>> * one idea is that Rob, Kevin and I take it in turns to publish a blog
>> post such that there is at least one new blog post every week
>> * blog posts should also be cross posted to blogs.apache.org (which will
>> hit some other aggregators)
>> * publicise blog posts in twitter using #apache #isis hashtags
>> * publicise blog posts via dzone.com (and any other places you might
>> choose)
>> * publicise blog posts via isis-dev mailing list, and ask others to
>> up-vote in dzone).
>>
>> In terms of content, one question raised was what, exactly, to blog
>> about.  My thoughts are:
>> * choose a theme for a series of blogs:
>>    - eg tips-n-tricks taken from applications working on (Robert's
>> PlanChaser, or Kevin's various apps)
>>    - copy-n-paste some of the sidebars from the Richard/Robert's original
>> Naked Objects book (for Robert)
>>    - work through some of the applib conventions, eg how to do choices
>> for a property.
>>
>> In terms of "how to":
>> * keep it short, something that won't take more than 2 or 3 minutes to
>> read
>> * if you have more than that, then leave it to the next part
>> * sit down and write 2 or 3 posts at a time (or split up a draft blog
>> post that's got too long) and then only publish them according to a schedule
>>
>>
>> *Articles*
>>
>> Rob, Kevin and I didn't discuss writing articles in our call; clearly
>> some articles would be good (eg infoq.com or theserverside.com), but it
>> takes that much more time to do.  I'd rather focus on just getting a steady
>> stream of blog posts going first.
>>
>>
>> *Thoughts?*
>>
>> OK, I think that more or less summarises the points that I wanted to
>> raise.  If anyone has any views on this/clarifications/corrections, then
>> post them here.
>>
>> Meantime, I intend to put some additional material on blogging up onto
>> our wiki.
>>
>>
>> Thanks,
>> Dan
>>
>> [1]
>> http://osdir.com/ml/general.incubator.apache.org/2011-11/msg00182.html
>> [2] http://restfulobjects.org/
>> [3] https://cwiki.apache.org/confluence/display/ISIS/RevampedSiteIdeas
>>
>
>
>

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

Thanks for this, Luis (I'm cc'ing my reply isis-dev, if that's ok).

We do have a quick start, but from your mail I'm guessing you found it 
hidden away.  I think it makes sense to highlight this up on the home 
page more clearly.

In terms of cool apps, do you have any thoughts?  (eg have you written 
one you'd like to donate?!)

~~~
A related idea to engage people is to get our apps deployed as running 
demos.  If we're restricting them to just the REST viewer and HTML 
viewer, then I think that would be feasible.

In terms of how to do this, one option might be to use Amazon EC2's 
Elastic Bean Stalk - which can be free for micro usage, I understand 
(http://aws.amazon.com/elasticbeanstalk/#pricing).  If someone fancied 
learning how to use this service...?

Cheers
Dan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On 21/11/2011 17:08, Luis Bender wrote:
> Dan,
>
> The first experience a developer gets from playing with the framework 
> will very much determine if he will continue to evaluate the 
> technology or try something else.
>
> So, I think we should maximize this first experience with a very easy 
> step-by-step quick start and some very cool ready to run apps.
>
> Just my /2/¢.
>
> Regards,
>
> Luis Bender
> ProcessMind Business Process Applications
> +55 11 5505-3213 Office
> +55 11 8158-8820 Mobile
> Skype: luis.bender
> <http://www.processmind.com.br/>
> website <http://www.processmind.com.br/> | blog 
> <http://thebpmexperience.wordpress.com/> | bpm forum 
> <http://br.groups.yahoo.com/group/BPM-Forum/> | twitter 
> <http://twitter.com/processmind> | jobone <http://www.jobone.com.br/>
>
>
>
>
> 2011/11/21 Dan Haywood <dan@haywood-associates.co.uk 
> <ma...@haywood-associates.co.uk>>
>
>     There's been an interesting thread going on in incubator@a.o
>     <ma...@a.o> [1] about (a) the number of podlings in the
>     incubator and (b) how long some of them are taking to graduate. 
>     One of the main points being made is that podlings that have been
>     in the incubator for a certain period of time (no-one is
>     suggesting how long exactly, but 1 year is being used as a
>     strawman in the thread) should be more explicit in defining their
>     roadmap and action steps towards graduation.
>
>     To be honest, this is all very reasonable, but from Isis' point of
>     view it is perhaps slightly worrying, because although we've made
>     some progress with getting our code etc together (and the
>     licenses, ICLAs, release processes etc are in good shape), we
>     haven't made a lot of progress in attracting new committers. 
>     Indeed, arguably we've gone backwards in that space: right now
>     only Kevin, Rob and myself currently actively commit.
>
>     With that in mind, Kevin, Rob and I had a skype conf call this
>     weekend to discuss some ideas to move Isis forward towards
>     graduation.  Obviously, this is it's slightly against Apache
>     policy ("if it didn't happen on the mailing list then it didn't
>     happen"), which is why I'm posting here now to post some of our
>     initial conclusions and to broaden out the discussion to everyone
>     else who might be interested.  (Kevin and Rob: correct me if I
>     overstate on any of this).
>
>
>     *Marketing Message*
>
>     The main thing we discussed was the "marketing message" for Isis.
>
>     /Automatic UI/
>
>     The view we came to was that the automatic-UI generation part of
>     Isis (ie the naked objects pattern) is possibly more of a negative
>     than a positive, at least so far as attracting new users:
>     * That is, for those that have heard of naked objects (guestimate:
>     1/4 to 1/3 of developers), chances are that they have dismissed it
>     as being a way to build over-simplified CRUD-style applications. 
>     (Of course, those of us who have actually used it to build apps
>     know that ain't so, but that's a different discussion).
>     * For those that have not heard of naked objects, the proposition
>     that "here's a framework that will automatically generate your
>     UIs" doesn't resonate.  Why? I guess we can speculate; my view is
>     that there are now plenty of UI technologies that are quite
>     productive/easy to use/fun; probably a lot more so than when the
>     original naked objects framework was developed c: 2000.  Another
>     reason might be that developers put too much emphasis over owning
>     the UI rather than making sure the domain model is good.
>
>     On the other hand, we did conclude that the automatic-UI is useful
>     as a design tool, and would-be users of Isis could probably
>     understand it in those terms.  The fact that the automatic UI is
>     also suitable for use by end-users in some situations is
>     subsidiary and something that adopters of Isis might discover only
>     later on.
>
>     /REST/
>
>     Another point that I was keen to see factored into the marketing
>     message for Isis is its REST support (the json-viewer).  As you
>     may have picked up from other posts, I've been developing a
>     standalone spec, Restful Objects [2], which defines defines a set
>     of RESTful resources, and corresponding JSON representations, for
>     accessing and manipulating a domain object model.
>
>     I'm quite excited by this Restful stuff.  On the one hand, as well
>     as Isis' implementation, there's also another .NET implementation
>     underway via Naked Objects MVC (Richard Pawson has been providing
>     great feedback on the spec).  And Johan Andries has been making
>     good progress on a new RESTful UI, which I'm hoping might go open
>     source.  Also, the REST approach has met a good reaction at our
>     (joint) client in Ireland.
>
>     In terms of marketing, my view is that REST is an area where there
>     is currently a lot of interest, but developers looking into it
>     will likely realise that it's a complex area to do right (ful
>     support for HATEOAS, HTTP headers and status codes etc).  As such,
>     developers might be interested in a framework that can help them
>     out, at a somewhat higher level of abstraction than JSR-311.  The
>     proposition is: press a button and get a complete, fully restful
>     API to any domain model.
>
>     /DDD/
>
>     A third message is for those that are interested in domain
>     modelling/domain driven design, for whom the automatic UI might
>     (again) be a useful design tool who might want to deploy their app
>     on some other framework, eg Spring or JEE.
>
>     So, overall this gives us three target use cases to address.  The
>     view we took on was that the home page should reflect these use cases:
>     - domain modelling (and deploy on own platform)
>     - REST
>     - automatically generated webapp (primarily to support the other
>     two use cases, but optionally as a deployment in its own right)
>
>     With this in mind I've sketched up a new graphic that could be
>     used for the home page, see [3].  The current home page (the
>     hexagonal architecture) would probably be demoted to a supporting
>     page describing the architecture of Isis.
>
>     In addition, we thought that the side bar menu should be
>     restructured around these use cases.
>
>
>     *Alpha status viewers*
>
>     Another point we discussed was the incomplete nature of some of
>     the viewers.  Having would-be users come across code that is
>     broken is clearly not a good experience, at least if there
>     expectations are that everything works.
>
>     Specifically:
>     * the scimpi viewer is code complete but its supporting
>     documentation is incomplete
>     * the wicket viewer is not complete (though it's documentation is
>     pretty good!)
>     * the xhtml viewer (which is a precursor to the json viewer, but
>     using XHTML representations) is superceded by the json viewer and
>     so should be removed
>     * the dnd viewer (which has worked in the past), is currently
>     broken (doesn't repaint properly)
>
>     We discussed the dnd viewer quite a lot.  Although it is, in some
>     sense, the "purest" expression of the naked objects pattern
>     (bringing in some of the original ideas of expressive systems),
>     the truth, probably, is that for our target audience this isn't
>     important to emphasise.  Crudely put: would-be users are not going
>     to understand what the somewhat unconventionaly UI that the dnd
>     browser provides is trying to achieve.  The fact that it is
>     currently broken hardly helps atters.
>
>     So one of the points we thought made sense was to change things so
>     that the HTML viewer is the default, rather than DnD.
>
>     In terms of the documentation and the site, we decided that the
>     web site pages for the scimpi, wicket and dnd viewers should
>     indicate that they are "alpha" status, and on the left hand menu
>     we should group them under "other viewers".  As such, we probably
>     should remove them from the Maven archetype until such time that
>     they are back to production quality.
>
>
>     *Remoting*
>
>     We also discussed the remoting component.  The remoting component
>     enables the dnd viewer to be deployed in a client/server
>     configuration, and is what is used in the big Irish project (on
>     the old .NET version of the naked objects framework).  However, my
>     personal view is that remoting is, well, broken.  In fact, I think
>     it should be removed: (a) the caching semantics for client-side
>     domain objects is not well-defined; (b) anyone wanting a
>     client/server solution would probably look towards an approach
>     that uses REST, (c) the remoting support introduces a lot of
>     complexity in the default runtime (notably, the separation of the
>     "Persistor" API and the "ObjectStore" API).
>
>     However, we didn't necessarily all agree on this viewpoint.  So
>     for now, we decided to de-emphasise remoting, because it doesn't
>     fit into the 3 main use cases that we highlighted above.  That
>     means that it won't appear in the left-hand menu, for example.  My
>     suggestion is that we link to it from the dnd viewer page (because
>     that's the only viewer that would make use of it).
>
>
>     *Release*
>
>     Kevin has been working through the release procedures that I
>     documented, and made some changes and clarifications.  I think
>     that by-and-large they are holding up ok.
>
>     I offered to push out a new release, because we are well overdue
>     for another release.   I propose to do this once we've
>     restructured the site a little (assuming that we go with the ideas
>     I'm summarizing in this thread).
>
>
>     *Blogging*
>
>     In terms of building up a community, I suggested that we need to
>     be more organized about blogging.  A little organization here
>     between the contributors could substantially increase Isis' reach:
>
>     * one idea is that Rob, Kevin and I take it in turns to publish a
>     blog post such that there is at least one new blog post every week
>     * blog posts should also be cross posted to blogs.apache.org
>     <http://blogs.apache.org> (which will hit some other aggregators)
>     * publicise blog posts in twitter using #apache #isis hashtags
>     * publicise blog posts via dzone.com <http://dzone.com> (and any
>     other places you might choose)
>     * publicise blog posts via isis-dev mailing list, and ask others
>     to up-vote in dzone).
>
>     In terms of content, one question raised was what, exactly, to
>     blog about.  My thoughts are:
>     * choose a theme for a series of blogs:
>        - eg tips-n-tricks taken from applications working on (Robert's
>     PlanChaser, or Kevin's various apps)
>        - copy-n-paste some of the sidebars from the Richard/Robert's
>     original Naked Objects book (for Robert)
>        - work through some of the applib conventions, eg how to do
>     choices for a property.
>
>     In terms of "how to":
>     * keep it short, something that won't take more than 2 or 3
>     minutes to read
>     * if you have more than that, then leave it to the next part
>     * sit down and write 2 or 3 posts at a time (or split up a draft
>     blog post that's got too long) and then only publish them
>     according to a schedule
>
>
>     *Articles*
>
>     Rob, Kevin and I didn't discuss writing articles in our call;
>     clearly some articles would be good (eg infoq.com
>     <http://infoq.com> or theserverside.com
>     <http://theserverside.com>), but it takes that much more time to
>     do.  I'd rather focus on just getting a steady stream of blog
>     posts going first.
>
>
>     *Thoughts?*
>
>     OK, I think that more or less summarises the points that I wanted
>     to raise.  If anyone has any views on
>     this/clarifications/corrections, then post them here.
>
>     Meantime, I intend to put some additional material on blogging up
>     onto our wiki.
>
>
>     Thanks,
>     Dan
>
>     [1]
>     http://osdir.com/ml/general.incubator.apache.org/2011-11/msg00182.html
>     [2] http://restfulobjects.org/
>     [3]
>     https://cwiki.apache.org/confluence/display/ISIS/RevampedSiteIdeas
>
>

Re: Thoughts on how to grow our community.

[Mike Burton <mi...@mycosystems.co.uk>]

Hi Dan,

I'd be happy to host some demos. I was hoping to make time to build Isis and maybe Claims model for this, but if you're happy to "do the work" I'm sure it will happen quicker. I'll send you login credentials.

Mike


On 22 Nov 2011, at 07:34, Dan Haywood wrote:

> On 22 November 2011 06:46, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> 
>> Dan,
>> 
>> Looks much better - and to the point. No mention of auto-persistance
>> though, is that intentional?
>> 
> That's a good point; it probably deserves a sentence on the home page.
> 
> 
>> 
>> Just a quickie: the links in the sentances "You can browse the app
>> either as a RESTful back-end, or as a standalone webapp. We've also
>> linked to the application's source so you can see how little code you
>> need to write." don't work. Neither do the usecases exists, but I
>> assume you're still working on them..
>> 
> 
> Yes, I am.
> 
> Is there anyone on the list who has a hosted server where we could deploy
> some simple apps?  I'm happy to do the work if you give me some login
> credentials.
> 
> 
> 
> 
>> 
>> I need to leave now for the morning.
>> 
>> WRT persistance, I'll start blogging on the apache Isis blog page about
>> setting up and using the JDBC/SQL objectstore..
>> 
> Good stuff.
> 
> 
> 
>> 
>> Regards,
>> Kevin
>> 
>> 
>> On 22 Nov 2011 at 0:02, Dan Haywood wrote:
>> 
>>> just as an fyi, I've done some initial work on updating the site.
>>> 
>>> To check it out:
>>> - svn up
>>> - mvn site-deploy -D modules=site -D deploy=local -o
>>> - cd /tmp/m2-sites/isis
>>> - open index.html
>>> 
>>> Opinions welcome!
>> 
>> 

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

On 22 November 2011 06:46, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:

> Dan,
>
> Looks much better - and to the point. No mention of auto-persistance
> though, is that intentional?
>
That's a good point; it probably deserves a sentence on the home page.


>
> Just a quickie: the links in the sentances "You can browse the app
> either as a RESTful back-end, or as a standalone webapp. We've also
> linked to the application's source so you can see how little code you
> need to write." don't work. Neither do the usecases exists, but I
> assume you're still working on them..
>

Yes, I am.

Is there anyone on the list who has a hosted server where we could deploy
some simple apps?  I'm happy to do the work if you give me some login
credentials.




>
> I need to leave now for the morning.
>
> WRT persistance, I'll start blogging on the apache Isis blog page about
> setting up and using the JDBC/SQL objectstore..
>
Good stuff.



>
> Regards,
> Kevin
>
>
> On 22 Nov 2011 at 0:02, Dan Haywood wrote:
>
> > just as an fyi, I've done some initial work on updating the site.
> >
> > To check it out:
> > - svn up
> > - mvn site-deploy -D modules=site -D deploy=local -o
> > - cd /tmp/m2-sites/isis
> > - open index.html
> >
> > Opinions welcome!
>
>

Re: Thoughts on how to grow our community.

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

Dan,

Looks much better - and to the point. No mention of auto-persistance 
though, is that intentional?

Just a quickie: the links in the sentances "You can browse the app 
either as a RESTful back-end, or as a standalone webapp. We've also 
linked to the application's source so you can see how little code you 
need to write." don't work. Neither do the usecases exists, but I 
assume you're still working on them..

I need to leave now for the morning.

WRT persistance, I'll start blogging on the apache Isis blog page about 
setting up and using the JDBC/SQL objectstore.. 

Regards,
Kevin


On 22 Nov 2011 at 0:02, Dan Haywood wrote:

> just as an fyi, I've done some initial work on updating the site.
> 
> To check it out:
> - svn up
> - mvn site-deploy -D modules=site -D deploy=local -o
> - cd /tmp/m2-sites/isis
> - open index.html
> 
> Opinions welcome!

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

Try using Chrome with either json view [1] or the more powerful rest
console [2].

hopefully you'll get the gist!

Cheers
Dan

[1]
https://chrome.google.com/webstore/detail/chklaanhfefbnpoihckbnefhakgolnmc
[2]
https://chrome.google.com/webstore/detail/cokgbflfommojglbmbpenpphppikmonn


On 22 November 2011 17:39, Mike Burton <mi...@mycosystems.co.uk> wrote:

> oops...
>
> Please ignore my hasty comments re  ... just gave me JSON text on browser
> page...
> I know see that this is exactly the point
>
> Mike
>
>
> On 22 Nov 2011, at 17:32, Mike Burton wrote:
>
> > Hi Dan,
> >
> > I had a quick go at this, looks good.
> > I found a few problems, some maybe down to config/ environment issues...
> >
> > When I first ran your suggested:   mvn site-deploy -D modules=site -D
> deploy=local -o
> > it errored with 2 missing artefacts:
> >   org.apache.isis:applib:jar:0.1.2-RC3-incubating
> >   org.apache.isis.core:testsupport:jar:0.1.2-RC3-incubating
> >
> > I found I needed to do the following instead, as per Wiki, which was OK:
> >  mvn site-deploy -D modules=standard -D site=full -D deploy=local
> >
> > Looking at the target/site/index.html that this created, the links under
> "Isis Modules" all gave "not found", I'm missing these folders under my
> local target/site:
> > - runtimes/  viewer/  progmodels/  security/
> > Do I need a different mvn command to generate these?
> >
> >
> > Looking in "Presentation Materials" (pdf slides) I tried this command:
> > mvn archetype:generate                                     \
> >    -D archetypeCatalog=http://incubator.apache.org/isis   \
> >    -D archetypeGroupId=org.apache.isis.support            \
> >    -D archetypeArtifactId=quickstart-archetype
> > Which seemed to work OK, as per wiki
> >
> >
> > I think I'm missing something re the JSON viewer...
> > I built and ran the app as per wiki, then when I did:
> >  - cd tmp/myapp ;
> >  - cd quickrun; mvn antrun:run -D exec=json
> > an Isis splash-screen appeared briefly, then browsing to
> http://localhost:8080/ just showed the JSON as text.
> >
> >
> > Trying the other way to run JSON viewer, after:
> >  cd viewer-json; mvn jetty:run
> > The URI on page: http://incubator.apache.org/isis/quickstart-app.htmlneeds correcting,
> > instead of: http://localhost:8080/myapp-quickviewer-scimpi
> > I needed to do:  http://localhost:8080/myapp-viewer-json/
> > Again it just gave me JSON text on browser page.
> >
> > HTML restful viewer worked (in Safari as well as Firefox) , but gave a
> stacktrace when clicking "user" and a few other places.
> > As above, page http://incubator.apache.org/isis/quickstart-app.htmlneeds changing,
> > http://localhost:8080/myapp-quickviewer-xhtml  should read:
> http://localhost:8080/myapp-viewer-xhtml/
> >
> > Mike
> >
> >
> > On 22 Nov 2011, at 00:02, Dan Haywood wrote:
> >
> >> just as an fyi, I've done some initial work on updating the site.
> >>
> >> To check it out:
> >> - svn up
> >> - mvn site-deploy -D modules=site -D deploy=local -o
> >> - cd /tmp/m2-sites/isis
> >> - open index.html
> >>
> >> Opinions welcome!
> >>
> >> Dan
> >>
> >>
> >
>
>

Re: Thoughts on how to grow our community.

[Mike Burton <mi...@mycosystems.co.uk>]

oops...

Please ignore my hasty comments re  ... just gave me JSON text on browser page...
I know see that this is exactly the point

Mike


On 22 Nov 2011, at 17:32, Mike Burton wrote:

> Hi Dan,
> 
> I had a quick go at this, looks good.
> I found a few problems, some maybe down to config/ environment issues...
> 
> When I first ran your suggested:   mvn site-deploy -D modules=site -D deploy=local -o
> it errored with 2 missing artefacts: 
>   org.apache.isis:applib:jar:0.1.2-RC3-incubating
>   org.apache.isis.core:testsupport:jar:0.1.2-RC3-incubating
> 
> I found I needed to do the following instead, as per Wiki, which was OK:
>  mvn site-deploy -D modules=standard -D site=full -D deploy=local
> 
> Looking at the target/site/index.html that this created, the links under "Isis Modules" all gave "not found", I'm missing these folders under my local target/site:
> - runtimes/  viewer/  progmodels/  security/
> Do I need a different mvn command to generate these?
> 
> 
> Looking in "Presentation Materials" (pdf slides) I tried this command:
> mvn archetype:generate                                     \
>    -D archetypeCatalog=http://incubator.apache.org/isis   \
>    -D archetypeGroupId=org.apache.isis.support            \
>    -D archetypeArtifactId=quickstart-archetype
> Which seemed to work OK, as per wiki
> 
> 
> I think I'm missing something re the JSON viewer...
> I built and ran the app as per wiki, then when I did:
>  - cd tmp/myapp ; 
>  - cd quickrun; mvn antrun:run -D exec=json
> an Isis splash-screen appeared briefly, then browsing to http://localhost:8080/ just showed the JSON as text.
> 
> 
> Trying the other way to run JSON viewer, after:
>  cd viewer-json; mvn jetty:run
> The URI on page: http://incubator.apache.org/isis/quickstart-app.html needs correcting,
> instead of: http://localhost:8080/myapp-quickviewer-scimpi  
> I needed to do:  http://localhost:8080/myapp-viewer-json/ 
> Again it just gave me JSON text on browser page.
> 
> HTML restful viewer worked (in Safari as well as Firefox) , but gave a stacktrace when clicking "user" and a few other places.
> As above, page http://incubator.apache.org/isis/quickstart-app.html needs changing,
> http://localhost:8080/myapp-quickviewer-xhtml  should read:  http://localhost:8080/myapp-viewer-xhtml/
> 
> Mike
> 
> 
> On 22 Nov 2011, at 00:02, Dan Haywood wrote:
> 
>> just as an fyi, I've done some initial work on updating the site.
>> 
>> To check it out:
>> - svn up
>> - mvn site-deploy -D modules=site -D deploy=local -o
>> - cd /tmp/m2-sites/isis
>> - open index.html
>> 
>> Opinions welcome!
>> 
>> Dan
>> 
>> 
> 

Re: Thoughts on how to grow our community.

[Mike Burton <mi...@mycosystems.co.uk>]

Hi Dan,

I had a quick go at this, looks good.
I found a few problems, some maybe down to config/ environment issues...

When I first ran your suggested:   mvn site-deploy -D modules=site -D deploy=local -o
 it errored with 2 missing artefacts: 
   org.apache.isis:applib:jar:0.1.2-RC3-incubating
   org.apache.isis.core:testsupport:jar:0.1.2-RC3-incubating

I found I needed to do the following instead, as per Wiki, which was OK:
  mvn site-deploy -D modules=standard -D site=full -D deploy=local

Looking at the target/site/index.html that this created, the links under "Isis Modules" all gave "not found", I'm missing these folders under my local target/site:
 - runtimes/  viewer/  progmodels/  security/
Do I need a different mvn command to generate these?


Looking in "Presentation Materials" (pdf slides) I tried this command:
mvn archetype:generate                                     \
    -D archetypeCatalog=http://incubator.apache.org/isis   \
    -D archetypeGroupId=org.apache.isis.support            \
    -D archetypeArtifactId=quickstart-archetype
Which seemed to work OK, as per wiki


I think I'm missing something re the JSON viewer...
I built and ran the app as per wiki, then when I did:
  - cd tmp/myapp ; 
  - cd quickrun; mvn antrun:run -D exec=json
an Isis splash-screen appeared briefly, then browsing to http://localhost:8080/ just showed the JSON as text.


Trying the other way to run JSON viewer, after:
  cd viewer-json; mvn jetty:run
The URI on page: http://incubator.apache.org/isis/quickstart-app.html needs correcting,
instead of: http://localhost:8080/myapp-quickviewer-scimpi  
I needed to do:  http://localhost:8080/myapp-viewer-json/ 
Again it just gave me JSON text on browser page.

HTML restful viewer worked (in Safari as well as Firefox) , but gave a stacktrace when clicking "user" and a few other places.
As above, page http://incubator.apache.org/isis/quickstart-app.html needs changing,
 http://localhost:8080/myapp-quickviewer-xhtml  should read:  http://localhost:8080/myapp-viewer-xhtml/

Mike


On 22 Nov 2011, at 00:02, Dan Haywood wrote:

> just as an fyi, I've done some initial work on updating the site.
> 
> To check it out:
> - svn up
> - mvn site-deploy -D modules=site -D deploy=local -o
> - cd /tmp/m2-sites/isis
> - open index.html
> 
> Opinions welcome!
> 
> Dan
> 
> 

Re: Thoughts on how to grow our community.

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

Thanks Dan,

I'll have a look later when I get a chance.

Regards,
Kevin

On 22 Nov 2011 at 0:02, Dan Haywood wrote:

> just as an fyi, I've done some initial work on updating the site.
> 
> To check it out:
> - svn up
> - mvn site-deploy -D modules=site -D deploy=local -o
> - cd /tmp/m2-sites/isis
> - open index.html
> 
> Opinions welcome!
> 
> Dan

Re: Thoughts on how to grow our community.

[Dan Haywood <da...@haywood-associates.co.uk>]

just as an fyi, I've done some initial work on updating the site.

To check it out:
- svn up
- mvn site-deploy -D modules=site -D deploy=local -o
- cd /tmp/m2-sites/isis
- open index.html

Opinions welcome!

Dan