[jira] [Updated] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Keir Haywood updated ISIS-1303: -- Fix Version/s: 2.0.0 > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish > Components: Isis Docs Website >Affects Versions: 1.11.1 >Reporter: Daniel Keir Haywood >Priority: Major > Fix For: 2.0.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, > ApacheGestalt.jpg, Offset-curves-of-sinus-curve.svg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI (data/context/interactions). > - "clean" "pure" "essential" pojo programming model > - agile, lean > - breaking down barriers between IT and business > Of these, I think that hexagonal architecture looks the best fit; it is well > regarded as a concept among the "cognoscenti", but there are surprisingly no > open source frameworks out there (at least in the Java space) that position > themselves as being the natural choice. > Therefore, I think a name - and appropriate short tag line - based around > this idea of hexagonal architecture should be considered. > Candidate names: > - hex (might hit trademark issues) > - hexagon > - hexagn (deliberately mis-spelled) > - hxg (omitting
[jira] [Closed] (ISIS-826) Remove WrappedObject interface, use instead WrappingObject as its replacement.
[ https://issues.apache.org/jira/browse/ISIS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Keir Haywood closed ISIS-826. > Remove WrappedObject interface, use instead WrappingObject as its replacement. > -- > > Key: ISIS-826 > URL: https://issues.apache.org/jira/browse/ISIS-826 > Project: Isis > Issue Type: Improvement > Components: Isis Applib (programming model) >Affects Versions: core-1.5.0 >Reporter: Daniel Keir Haywood >Assignee: Daniel Keir Haywood >Priority: Major > Fix For: 2.0.0-M5 > > > For example, WrappedObject defines save() and wrapped(). If the underlying > domain object also defined these methods as actions, then it would be > impossible to use the wrapper to check business rules etc. > Therefore should remove this interface (in Isis 2.x), to replace with one > that uses methods which are unlikely to cause a clash. > (The workaround in the meantime is to rename the action methods and use > @Named() if required for the UI). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ISIS-826) Remove WrappedObject interface, use instead WrappingObject as its replacement.
[ https://issues.apache.org/jira/browse/ISIS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Keir Haywood resolved ISIS-826. -- Resolution: Fixed This was implemented in an earlier release; just cleaning up the backlog here. > Remove WrappedObject interface, use instead WrappingObject as its replacement. > -- > > Key: ISIS-826 > URL: https://issues.apache.org/jira/browse/ISIS-826 > Project: Isis > Issue Type: Improvement > Components: Isis Applib (programming model) >Affects Versions: core-1.5.0 >Reporter: Daniel Keir Haywood >Assignee: Daniel Keir Haywood >Priority: Major > Fix For: 2.0.0-M5 > > > For example, WrappedObject defines save() and wrapped(). If the underlying > domain object also defined these methods as actions, then it would be > impossible to use the wrapper to check business rules etc. > Therefore should remove this interface (in Isis 2.x), to replace with one > that uses methods which are unlikely to cause a clash. > (The workaround in the meantime is to rename the action methods and use > @Named() if required for the UI). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ISIS-826) Remove WrappedObject interface, use instead WrappingObject as its replacement.
[ https://issues.apache.org/jira/browse/ISIS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Keir Haywood reassigned ISIS-826: Assignee: Daniel Keir Haywood > Remove WrappedObject interface, use instead WrappingObject as its replacement. > -- > > Key: ISIS-826 > URL: https://issues.apache.org/jira/browse/ISIS-826 > Project: Isis > Issue Type: Improvement > Components: Isis Applib (programming model) >Affects Versions: core-1.5.0 >Reporter: Daniel Keir Haywood >Assignee: Daniel Keir Haywood >Priority: Major > Fix For: 2.0.0-M5 > > > For example, WrappedObject defines save() and wrapped(). If the underlying > domain object also defined these methods as actions, then it would be > impossible to use the wrapper to check business rules etc. > Therefore should remove this interface (in Isis 2.x), to replace with one > that uses methods which are unlikely to cause a clash. > (The workaround in the meantime is to rename the action methods and use > @Named() if required for the UI). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ISIS-826) Remove WrappedObject interface, use instead WrappingObject as its replacement.
[ https://issues.apache.org/jira/browse/ISIS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Keir Haywood updated ISIS-826: - Fix Version/s: 2.0.0-M5 > Remove WrappedObject interface, use instead WrappingObject as its replacement. > -- > > Key: ISIS-826 > URL: https://issues.apache.org/jira/browse/ISIS-826 > Project: Isis > Issue Type: Improvement > Components: Isis Applib (programming model) >Affects Versions: core-1.5.0 >Reporter: Daniel Keir Haywood >Priority: Major > Fix For: 2.0.0-M5 > > > For example, WrappedObject defines save() and wrapped(). If the underlying > domain object also defined these methods as actions, then it would be > impossible to use the wrapper to check business rules etc. > Therefore should remove this interface (in Isis 2.x), to replace with one > that uses methods which are unlikely to cause a clash. > (The workaround in the meantime is to rename the action methods and use > @Named() if required for the UI). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ISIS-439) Remove concept of mutable collections from programming model.
[ https://issues.apache.org/jira/browse/ISIS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Keir Haywood reassigned ISIS-439: Assignee: Daniel Keir Haywood > Remove concept of mutable collections from programming model. > - > > Key: ISIS-439 > URL: https://issues.apache.org/jira/browse/ISIS-439 > Project: Isis > Issue Type: Improvement > Components: Isis Applib (programming model) >Affects Versions: viewer-wicket-1.2.0 >Reporter: Daniel Keir Haywood >Assignee: Daniel Keir Haywood >Priority: Major > Fix For: 2.0.0-M5 > > > was: Wicket viewer should support mutable collections - ie with an implicit > 'add' and 'remove' action. > but see comments underneath. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ISIS-439) Remove concept of mutable collections from programming model.
[ https://issues.apache.org/jira/browse/ISIS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Keir Haywood updated ISIS-439: - Fix Version/s: 2.0.0-M5 > Remove concept of mutable collections from programming model. > - > > Key: ISIS-439 > URL: https://issues.apache.org/jira/browse/ISIS-439 > Project: Isis > Issue Type: Improvement > Components: Isis Applib (programming model) >Affects Versions: viewer-wicket-1.2.0 >Reporter: Daniel Keir Haywood >Priority: Major > Fix For: 2.0.0-M5 > > > was: Wicket viewer should support mutable collections - ie with an implicit > 'add' and 'remove' action. > but see comments underneath. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ISIS-2164) OpenTracing integration
[ https://issues.apache.org/jira/browse/ISIS-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Keir Haywood updated ISIS-2164: -- Fix Version/s: (was: 2.0.0) > OpenTracing integration > --- > > Key: ISIS-2164 > URL: https://issues.apache.org/jira/browse/ISIS-2164 > Project: Isis > Issue Type: New Feature > Components: Isis Viewer Wicket >Affects Versions: 1.17.0 >Reporter: Daniel Keir Haywood >Assignee: Daniel Keir Haywood >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
