On 1 December 2011 05:59, Dan Haywood <[email protected]> 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 <[email protected]> >> wrote: >> > There's been an interesting thread going on in [email protected] [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
