Hello, I'm sorry for the long reply. The first six minutes before the demonstration in the video[1] suggested by Adam focus on a question : "Why should I be interest?". I am at this stage, trying to find an answer to this question. In 2010 I was working on a project with a thousand pages business requirements document and after an huge work the team came out with the model. It was big with lot of classes, methods and relationships but it was not really that complex. Use case by use case, sitting with the domain experts and users, we started the design of the user interface with Balsamiq Mockups. You can imagine what it means to code the user interface drawings to views connect to the controllers and domain model. On regural basis, we released a working prototype for customer validation. Even if the user interface team was trained on the use of Balsamiq Mockups, a common issue was that many pages include a too much fields violating the no scroll-bar constraint. Back to the user, which is the only one who can really say what fields are really needed, the wonderful, modular, reusable piece of software able to display a domain object must to be polymorphic or it needs more than one view. Second issue actions presentation/logic: if the domain object has few actions, let's say up to 5, buttons works fine but when you have thirty-five operation may be something similar to a menu is more appropriated. Only a user, intended as the person that use the software to do his job, can say how many clicks away the action is supposed to be and may be he/she does not realize it at design time. When the system has been released in production we were impressed looking at the huge work the team did asking our self if we could find a better way. I find the Isis framework has the potential to solve most issues in a simple and smart way however to change, for example, the order in which fields are presented, you need to change a small thing in the Java source code. Here comes the question: "do we really need to change this?"
Cheers, Maurizio [1] http://www.youtube.com/watch?v=HexULqwBnAk&feature=youtu.be&t=13m 2013/2/14 Mohammad Nour El-Din <[email protected]> > Hi... > > > On Thu, Feb 14, 2013 at 4:16 PM, Maurizio Taverna < > [email protected] > > wrote: > > > Hello, > > I've been a Smalltalk guy (oh yes, I'm that old), so I watched with > > interest to the video presentation. > > What they did is really cool, and if you are a Smalltalk developer to > > really enjoy it. > > Thanks again to Adam for sharing. > > > > I would like to ask, what are we trying to get out of this ? And whom we > > > are targeting ? Because answering these question is critical to what > > > approach/tool(s) we want/will take > > > > > > > It seems we all agree on one point. > > The idea of providing a full features development environment online is a > > huge work and out of scope. > > I don't know any developer who will switch from his/her favourite fully > > integrated IDE > > to a 'limited' online environment. > > On the other side I know very few non-developers with an IDE on their > > computer, In my experience, just asking some like that to any IT manager > > sounds like crazy request. > > What I'm trying to figure out are the features of a workspace, shared > > between users and developers, that allows to work together on the domain > > model. > > Centre of the picture there is the a version control system, integrated > > with the IDE and the workspace. > > The workspace should have access only to the domain classes, presented as > > user interface. > > They should be able to work with the model (with limited functionality), > > as an interactive run-time, when done commit the changes, and the > > developers from their favourite IDE can update the project and implement > > the functionality. > > As additional functionality the workspace could allow the users to enter > > the data for fixtures, the business experts are usually pretty good in > > providing a set of significant data. > > Any feedback on this topic is very appreciated. > > > > Aha, interesting, that indeed another different scenario than the two I > have explained and indeed there is a very valid use case here, more over I > like the idea of having the version control as the connection between the > IDE and the workspace which abstracts the source of changes so > semi/developers can see each other changes as if any other developer(s) > made the changes and pushed/committed them to the repository > > I believe there a good consensus here then, why not to move the discussion > to more technical details more specifically the central point caused based > on that we can decide how and what to expose to the workspace cause from > the IDE side it will just be commit/push operation > > I would like to see if we can "eat out own dogs food" that is: > - Why not to think about the WIDE (Workspace IDE) to be an Isis RO client > and the domain model exposed over RO is actually our programming model > > What do you think about that direction ? > > > > Cheers > > Maurizio > > > > -- > Thanks > - Mohammad Nour > ---- > "Life is like riding a bicycle. To keep your balance you must keep moving" > - Albert Einstein >
