Re: [VOTE] Change the name of the framework.

[Patrick Pliessnig]

I thought I put down here some more meanings of Alma in addition to 
those already mentioned, in order to allow for hypothetical voices of 
international users not in the loop.


Hebrew: young woman,
Italian: fruitful,
Hungarian: apple,
Arab: on the water,
in the antiquity: deity of/for fertility, sex, pregnancy, childbirth 
(therefore 'alma mater')

Turkish: unity of volume
animal family of segmented worms (Latin: Almidae), home in Ethiopia
legendary man-beast in the world east of Moskow, west of Ulan Bator and 
north of Theran (similar to: Yeti, Bigfoot, Skunk Ape) [1]


Patrick

[1]
A russian imperial geographer described the alma as:
"We were told that it had a flat face like that of a human being, and
that it often walked on two legs, that its body was covered with a thick
black fur, and its feet armed with enormous claws; that its strength was
terrible, and that not only were hunters afraid of attacking it, but
that the inhabitants removed their habitations from those parts of the
country which it visited"


Am 09.06.2022 um 20:06 schrieb Dan Haywood:

Hi folks,

The vote has now been open for 14 days, but I'll keep it going a few days
more as we had quite a few votes over the last day or two.

Once I do close the vote, then will need to do some deeper due diligence on
trademarks etc.  We'll also kick off a logo competition and all those fun
sort of things.

For now, though here's the current state of play:

1. *Alma*: Johan*, Oscar*, Struberg*, Kevin*, Bilgin*, Alexander*,
Brian K, Fernando, Martin H,
2. *Causeway*: Andy*, Dan*, Joerg*, Rob*, Patrick, Martin W
3. *Kokoro  *: Dhruv

* = committer/PMC member.  Only these formally count, but we want to hear
as many voices as possible.

And here are remarks, positive and negative, for Alma and for Causeway as
names:

Alma +ve
" catchy"
* "write what you hear, very short"
* "alma in portuguese means soul"

Alma -ve
* AlmaLinux is a new Linux distribution (merge of CentOS and RHEL)
* 4918 hits in Global Brand DB [1] Search Results (vs 109 for Causeway)
* "common word ending up in conflict"
* "Alma does have a little baggage though... quite a few roads in the UK to
commemorate the battle of Alma"
* "Alma" means different things to different people.  As such it doesn't
really transport a single idea.

Causeway +ve
* "sounds intentional, will take you somewhere"
* A "Causeway" has a lot of marketing value [to bridge the gap between
business and techies]"
* "easy to say with and without Apache first.  Well known word, easy to
spell.  No weird or unfortunate connotation in Urban Dictionary.  I like
the hexagonal connection too."

Causeway -ve
* "hard to write for non-native speakers"
* "prefer non-english word to stand out in searches"
* "potentially difficult to pronounce in non-english langs"


Thx
Dan

[1] https://branddb.wipo.int/branddb/en/

On Thu, 9 Jun 2022 at 17:21, - -  wrote:


Please do.

R


On 09/06/2022 17:11 Dan Haywood  wrote:


Thanks for this, Rob. Do you mind if I cross-post to the thread on Slack
... ?

On Thu, 9 Jun 2022 at 17:08, - -  wrote:


Hi All
When we donated the Naked Objects project to Apache, all those years

ago,

we had to change its name. This was because a commercial version

(ported to

.NET) was the focus of the business and it used that original name.

That

name described the framework so well, even if it raised a few eyebrows.
Dan and I discussed new names at length, looking for something
descriptive, pithy and memorable. Given what we were changing it from,

the

task was rather hard. What we settled on gave us something unique and
terse, using something that was common to us three--we all lived in

towns

next to this river (more commonly known as the Thames)--and it also had
that goddess connection.
After a while that choice started to look poor. Unfortunately

associations

matter and I have no doubt there has been an effect to this. A local
friend, who invests in businesses in the area, commented to me that

many

companies in the area (particularly Oxford) have had to change their
company names over the recent years.
To me, this is reminiscent of an old VW Golf advert, where a guy is
wandering back from the casino and the voice over explains that he had

put

everything on black and it had come up red. He then gets into his Golf

and

the implication is that he still has the most important thing. We

started

with a great framework and picked the wrong name. Yet we still have the
important part.
To me Causeway sound intentional, it'll take you somewhere. This gets

my

vote. The others are fine, but I would put the simpler one first, so:

1)

Causeway; 2) Alma; 3) Kokoro.
Hey, but don't listen to me. Look what happened last time!
Best regards
Robert

On 24/05/2022 09:46 Dan Haywood 

wrote:

Hi folks,
We've talked a lot about changing the name of the framework, see for
example ISIS-1303 [1]. So this thread, is, finally, to start the

process

There have been an awful lot of suggestions; talking

Re: [VOTE] Change the name of the framework.

[Patrick Pliessnig]

"Alma" means different things to different people.
As such it doesn't really transport a single idea.
https://en.wikipedia.org/wiki/Alma

The islamic state "Isis" is a trend. But the River Thames and the
Egyptian goddess will stay.
So, there is no need to change the name.

"Kokoro" is a trendy Japanese word.
Apache Isis will hopefully live longer than this trend.

A "Causeway" is here to stay and it transports quite a few simple ideas 
of the framework.

Apache Isis website states:

   "But let’s not get distracted talking about methodologies. At the
   end of
   the day what really matters is communication between the domain experts
   (that is, the business) who need the system and the techies actually
   implementing it."

The whole idea of the framwork is "to bridge" the gap between business 
and techies. A "Causeway" has a lot of marketing value.


Hence, I prefer Causeway or stay with Isis.

Thanks
Patrick

Am 24.05.2022 um 10:46 schrieb Dan Haywood:

Hi folks,

We've talked a lot about changing the name of the framework, see for
example ISIS-1303 [1].  So this thread, is, finally, to start the process

There have been an awful lot of suggestions; talking informally/offline
with the other committers, we think there are a few front-runners.  So the
vote below lists these, but if none appeal then you can vote for something
else.

So, please cast vote your vote for one of the following:

1. change the framework's name to Apache *Alma*
2. change the framework's name to Apache *Causeway*
3. change the framework's name to Apache *Kokoro*
4 *don't change *the framework's name
5. do change the framework's name, but I don't like any of them, give me
some *other choices*!

Background on the first three choices:

*Alma* - technically speaking, is a piece of wood (a little round pole)
within a stringed instrument such as a violin [2], connecting the
soundboards etc.  What it means though "heart" or "soul" -think "alma
mater", so the metaphor is that we are connecting business with technology,
or acting as the heart of the business.

*Causeway* - taken from the Giant's Causeway in Northern Ireland, a
geological feature characterised by hexagonal basalt columns [3].  The
metaphor here is again "causeway" meaning bridge, but the hexagons also are
reminiscent of the hexagonal architecture common to DDD.

*Kokoro* - is a Japanese word meaning something connecting heart, mind,
body and spirit [4].  It has been trendy in the past to use Japanese words.

In case anyone wants a reminder, our current name *Isis* comes from the
name of the River Thames as it wanders through Oxford  (the original
authors of the framework all used to live in Oxfordshire).  Isis of course
was an Egyptian goddess [5].

For voting, hopefully there will be a clear winner, but it might make sense
to rank your preferences.  If there are no clear winners then, well, we'll
go round the loop - we don't want to force through a change that no-one is
happy with.

Normally votes are at least 72 hours, but we intend to keep this one open
longer than that, at least we've had a few contributions to the thread.
Only committers to the framework have a formal vote, but it'd be good to
hear the views of as many users of the framework as we can.

Thanks
Dan  (co-drafted with Johan).



[1]https://issues.apache.org/jira/browse/ISIS-1303
[2]
https://4.bp.blogspot.com/-odn0l-W5zow/Wmim3CiDJNI/G8c/ZiJPbHSbhHUEumzpxw1ZYNmIfb8IXnBjQCLcBGAs/s1600/20120919201309.jpg
[3]
https://en.wikipedia.org/wiki/Giant%27s_Causeway#/media/File:Causeway-code_poet-4.jpg
[4]
https://qz.com/946438/kokoro-a-japanese-word-connecting-mind-body-and-spirit-is-also-driving-scientific-discovery/
[5]
https://simple.wikipedia.org/wiki/Isis#:~:text=Isis%20is%20a%20goddess%20in,greatest%20goddesses%20of%20Ancient%20Egypt
.

Re: Extending the Programming Model with @Support?

[Patrick Pliessnig]

Am 23.09.2019 um 13:26 schrieb Andi Huber:
I do also prefer @Model. Only inconvenience is that there's already a 
@Model defined [1] with JEE.


Your proposed @Collection(rules={addTo, removeFrom}) would do the 
trick as well, but when typing that, your IDE will not provide any 
auto-completion, which might be a little cumbersome.


Thanks for the feedback though!

[1] 
https://docs.oracle.com/javaee/7/api/javax/enterprise/inject/Model.html


On 23.09.2019 10:14, Patrick Pliessnig wrote:
I think it's about model validation, not support validation. 
Therefore I prefer @Model to @Support


In my opinion the term 'support' is somewhat fuzzy. Supporting 
methods are business rules that helps model actions, properties, 
collections. Thus it could make sense to 'declare' those rules in one 
place together with other properties to document the intent.


eg:
you have a collection myCollection and you want rules that specifies 
how to add and remove a child. Then you could annotate myCollection 
with @Collection(rules={addTo, removeFrom}). The model validator 
could then fail fast if it does not find supporting methods with the 
required prefix. No cluttering.


Patrick


Am 23.09.2019 um 07:54 schrieb Andi Huber:
Yes, there are lots of cases already covered, but not those, when 
you get the intended supporting-method's prefix wrong.


Typically, when writing new domain-code I'd start with some 
properties and actions and then eventually add supporting-methods. 
At the time of writing these, I have a clear intent, that I want 
these to be added to the model no matter what, and I want to be 
warned when I get something wrong. This annotation (@Support or 
@Model) should allow me to express this intent. (However you don't 
have to, its optional.)


@Brian: You brought the 'addChild(Child ...)' example, where your 
intent is to have this as an Action? If so, the framework should be 
able to undersand this intent, when the addChild method is annotated 
with @Action. Otherwise we have a bug.


Cheers, Andi

On 2019/09/23 03:58:28, Dan Haywood  
wrote:

I'm afraid that I don't understand the idea.

There are already config properties that enable fail-fast 
validation that
detect orphaned supporting methods (and other checks besides).  Why 
do we
need an annotation to ask for this to be done? It just adds clutter 
in my

view?

D.

On Sun, 22 Sep 2019, 21:07 Brian K,  wrote:

I like the @Support annotation, not @Action, because validate is 
not an

action.

Most of my frustration on this front has been inadvertently 
creating a

supporting function.  like:
addChild(Child child){...}

Can these patterns be optional when the annotations are active?   
Maybe a

isis.properties switch?

Thanks!
Brian

On Sun, Sep 22, 2019 at 3:19 AM Andi Huber  wrote:


If we would not have the freedom of introducing a new annotation,
@Action(type=Supporting)
would be a good choice as well, but we also have supporting 
methods for

Properties and Collections!

But since we have @Action, @Property and @Collection all with good
justification to stand and represent their own kind, we might as 
well

introduce a new one here!?

I was also thinking about @Model, which is a bit more generic and 
may

allow for more flexible use later on.

On 2019/09/22 08:47:20, "Rade, Joerg / Kuehne + Nagel / HAM GI-DP"
 wrote:

Hi Andi,

I like the idea of using an annotation, because it makes the

programming

model more consistent.

Maybe @Action(type=Supporting) ?

-j
-Ursprüngliche Nachricht-
Von: Andi Huber [mailto:ahu...@apache.org]
Gesendet: Sonntag, 22. September 2019 10:01
An: users@isis.apache.org
Betreff: Extending the Programming Model with @Support?

Hi folks,

we are still making progress towards Apache Isis Version 2. 
While most
of the work goes into technical topics that stay under the hood, 
like

decoupling from JDO, there are also some changes to the programming

model,

that will affect you and require migration of your domain-code.
We have no concrete release plan yet, we thought maybe October 
for a

preview, we'll see.

Anyway I do have a questions regarding the programming model:

Have you ever run into the issue of misspelling a supporting-method

within your domain-code
eg. verifyMyAction(...) instead of correct validateMyAction(...) 
then

spending some time to troubleshot this? What an inconvenience!
My proposed solution to this is to introduce a new annotation to 
make a

contract with the domain-model (meta-model) :

@Action
public void myAction() {

}

@Support // <-- to enforce a contract with the domain-model
public boolean hideMyAction() {
 ...
}

* The 'hideMyAction' method is termed 'supporting-method'. We 
have lots

of variants of these. (validateX, disableX, ...)

* This contract allows for a check whether the intended
supporting-method gets picked up by the framework and is not 
ignored.

That
way we can emit a validation failure, if a support-method is 
misspelled

or

does have any other

Re: v2 - explicit vs implicit annotations

[Patrick Pliessnig]

Hi Dan

In a reuse scenario a local configuration of the annotation property is 
certainly useful. I guess that if you want to integrate an existing 
subdomain module into a destination application, a configuration 
property at the class or module level could ease the job.


Patrick


Am 28.12.2018 um 11:54 schrieb Dan Haywood:

Hi folks,

... and happy holidays!

We currently have the configuration property
"isis.reflector.explicitAnnotations.action" which if specified
requires @Action to be added as an annotation for all public methods that
don't represent properties/collections or supporting methods.  If this is
enabled then there's generally no need to annotate public methods that
aren't meant to be in the metamodel with the @Programmatic annotation.

Andi and I have just been discussing this (off-list) and wondering if we
should extend this in v2.  Our idea is maybe to allow this to be specified
at the class level, and to also have three levels rather than two:

- explicit : all properties, collections and actions must be annotated
- actions : actions must be annotated, but properties and collections need
not.  This is the behavior if the above configuration property is specified.
- implicit : no annotations are required.  This is the current default

So, we were thinking to add a value to @DomainObject, eg

@DomainObject(metamodelDiscoveryStrategy = EXPLICIT | ACTIONS | IMPLICIT |
AS_CONFIGURED)

where "AS_CONFIGURED" would read a new configuration property that would
take these three values (replacing the existing
"isis.reflector.explicitAnnotations.action".

Two questions:

1. is the idea of a new level to explicitly annotate everything (properties
and collections as well as actions) useful ?
2. is there a need to configure this on a class-by-class basis, or is a
global configuration property sufficient?

Thx
Dan

Re: We'd like to remove "isis.deploymentType" ... any objections?

[Patrick Pliessnig]

No problem

Am 28.10.2018 um 10:29 schrieb Andi Huber:

Hello everyone!

Dan and I discussed [1], whether we should remove the config option 
'isis.deploymentType'.

Remember, we are having this, in order for developers to decide, whether an 
Apache Isis App should be deployed in PROTOTYPING mode or not (PRODUCTION).

In the advent of Docker, we had to introduce support for a system environment 
variable (PROTOTYPING), that serves the exact same purpose.

Now, instead of having to support 2 possible ways to configure the deployment 
type, we would like to discontinue the first one. This relieves us from the 
burden of having to decide, which one has precedence over the other, and also 
having to document this somewhere. As a positive side-effect, developers are 
not encouraged to provide different war files for different deployment 
scenarios.

So we are asking you, do you have any strong objections regarding this move?

Cheers Andi!

[1] 
https://github.com/apache/isis/commit/4ea76029e097e3e8b94f5602ca430dfcd6ee9dac

Re: [ANNOUNCE] New Committer - Johan Doornenbal

[Patrick Pliessnig]

Hey Johan

It's great to know you on board the committer's team.
I trust you bring in yet another colour to one of the most exciting 
software journeys I've ever seen.


Patrick


Am 25.03.2018 um 12:34 schrieb Dan Haywood:

I'm delighted to announce that Johan Doornenbal has been voted in as a
committer on Apache Isis, and also as a member of the Isis PMC.  The first
gives Johan the right to commit changes directly to the Apache Isis
codebase, the second gives him the right to be involved in future votes.

Johan has an abundance of real-world experience in using the framework for
delivering business solutions.  He's been working with Jeroen and I for
several years now on Estatio [1], and is now responsible for specifying and
implementing the great proportion of the new functionality of that app.

For Apache Isis he contributed an extended version of the PetClinic
tutorial [2], and in terms of code has provided numerous contributions to
the companion Incode Platform, most notably for the Excel module [4] and on
a integration with mailchimp.  Informally he's provided great insight and
feedback on new features for the framework, the most recent example being
the implementation of checkboxes for parented collections [4].

I've really enjoyed working with Johan over the last few years, and I'm
very pleased he's joining as a committer and onto the PMC; he'll be a great
addition to our team.  Please join me in welcoming him to our happy band!

Dan Haywood
Apache Isis Committer

[1] http://github.com/estatio/estatio
[2]
http://isis.apache.org/versions/1.13.2/guides/tg.html#3.-pet-clinic-(extended)
[3] http://platform.incode.org/modules/lib/excel/lib-excel.html
[4]
http://isis.apache.org/guides/rgant/rgant.html#_rgant-Action_associateWith

RE: Tenancy restriction - entity that relates to more thanoneOtherentity.

[Patrick Pliessnig]

:-)

Am 12.12.2017 8:39 vorm. schrieb "Nikhil Dhamapurkar" <
nikhil.dhamapur...@healthengine.com.au>:

> Hi Patrick, Steve
>
> Thank for your responses, I have made the changes similar to what you guys
> have suggested.
> The context relating to desk / Org  was helpful.
>
> I have flattened the many to many relation entity  (practicePractitioner)
> which relates a practice and a patient, the admin or a super user will link
> a practitioner with a practice in this entity this way not exposing all
> Practitioners to every user and this entity can have their own version of
> Practitioner Name or Shortname as well.
>
> Also, to relate the Desk / Context instead of extending the
> ApplicationUser class to save the current login information, I am saving
> the UserRole and Practice its Organization in a separate table
> (RoleMapping). I read the role mapping in the ApplicationTenancyEvaluator
> and Hide or disable the entity based on this information
>
> Completed most of the changes yesterday and I can see I have the control
> as needed for the entity based on these changes thank you for your
> suggestions.
>
> Regards
> Nikhil
>
> From: Patrick Pliessnig
> Sent: 07 December 2017 11:42
> To: users@isis.apache.org
> Subject: Re: Tenancy restriction - entity that relates to more
> thanoneOtherentity.
>
> I wonder whether a metaphor for context could do a better job?
>
> Say, 'desk' instead of context. Then the user would have a currentDesk on
> login
>
> To model the desk an interesting question might be, who organizes the desk?
> Is it the practice for more standardization or rather the practitioner for
> more individualization?
>
>
> Am 06.12.2017 11:35 nachm. schrieb "Stephen Cameron" <
> steve.cameron...@gmail.com>:
>
> > Oops, ignore that comment in the Person about tenancy paths, they aren't
> > needed (yet).
> >
> > On Thu, Dec 7, 2017 at 9:33 AM, Stephen Cameron <
> > steve.cameron...@gmail.com>
> > wrote:
> >
> > > Hi Nikil,
> > >
> > > The context switching that Patrick is speaking of is what I was
> > suggesting
> > > before, but to make this work I think you have to extend the default
> > > application user and record the current context on your extended
> > > ApplicationUser. I've just done a test on this for my cooperation
> > project.
> > > In my situatioin there is a many-to-many relationship between
> > Organisation
> > > and Person, ( I have an OrganisationPerson entity for the join, so can
> > set
> > > a status property for each, either active or inactive)
> > >
> > > So I have a Person that references a current Organisation (context)
> > >
> > > @PersistenceCapable(identityType = IdentityType.DATASTORE, schema =
> > > "cooperation")
> > > @Inheritance(strategy = InheritanceStrategy.NEW_TABLE)
> > > @DomainObject()
> > > public class Person extends ApplicationUser {
> > >
> > > /*
> > >  * Allow a default Organisation to be set on the current user.
> > >  *
> > >  * Organisations have a list of linked users/Persons, but one user
> > > might link to
> > >  * multiple Organisations, but we want to restrict the visibility
> to
> > > one Organisation at a time.
> > >  *
> > >  * We restrict access to all data usinf the security module tenancy
> > > path, but this requires
> > >  * a current Organisation, that is set here a login, by the user
> > > having only one link to an
> > >  * Organisation, or, the user selecting one specifically. In the
> > later
> > > case the currently operating
> > >  * one will be saved from session to session.
> > >  *
> > >  */
> > > @Column(allowsNull="true", name="organisation_id")
> > > @Getter
> > > @Setter(value=AccessLevel.PACKAGE)
> > > private Organisation organisation;
> > >
> > > ...
> > >
> > > }
> > >
> > > Person is used by the security module instead of default
> ApplicationUser
> > > by having a domain service as follows:
> > >
> > > @DomainService(nature=NatureOfService.DOMAIN)
> > > public class MyApplicationUserFactory implements
> ApplicationUserFactory {
> > >
> > > @Override
> > > public ApplicationUser newApplicationUser() {
> > > final ApplicationUser object = new Person();
> > >

Re: Tenancy restriction - entity that relates to more than oneOtherentity.

[Patrick Pliessnig]

I wonder whether a metaphor for context could do a better job?

Say, 'desk' instead of context. Then the user would have a currentDesk on
login

To model the desk an interesting question might be, who organizes the desk?
Is it the practice for more standardization or rather the practitioner for
more individualization?


Am 06.12.2017 11:35 nachm. schrieb "Stephen Cameron" <
steve.cameron...@gmail.com>:

> Oops, ignore that comment in the Person about tenancy paths, they aren't
> needed (yet).
>
> On Thu, Dec 7, 2017 at 9:33 AM, Stephen Cameron <
> steve.cameron...@gmail.com>
> wrote:
>
> > Hi Nikil,
> >
> > The context switching that Patrick is speaking of is what I was
> suggesting
> > before, but to make this work I think you have to extend the default
> > application user and record the current context on your extended
> > ApplicationUser. I've just done a test on this for my cooperation
> project.
> > In my situatioin there is a many-to-many relationship between
> Organisation
> > and Person, ( I have an OrganisationPerson entity for the join, so can
> set
> > a status property for each, either active or inactive)
> >
> > So I have a Person that references a current Organisation (context)
> >
> > @PersistenceCapable(identityType = IdentityType.DATASTORE, schema =
> > "cooperation")
> > @Inheritance(strategy = InheritanceStrategy.NEW_TABLE)
> > @DomainObject()
> > public class Person extends ApplicationUser {
> >
> > /*
> >  * Allow a default Organisation to be set on the current user.
> >  *
> >  * Organisations have a list of linked users/Persons, but one user
> > might link to
> >  * multiple Organisations, but we want to restrict the visibility to
> > one Organisation at a time.
> >  *
> >  * We restrict access to all data usinf the security module tenancy
> > path, but this requires
> >  * a current Organisation, that is set here a login, by the user
> > having only one link to an
> >  * Organisation, or, the user selecting one specifically. In the
> later
> > case the currently operating
> >  * one will be saved from session to session.
> >  *
> >  */
> > @Column(allowsNull="true", name="organisation_id")
> > @Getter
> > @Setter(value=AccessLevel.PACKAGE)
> > private Organisation organisation;
> >
> > ...
> >
> > }
> >
> > Person is used by the security module instead of default ApplicationUser
> > by having a domain service as follows:
> >
> > @DomainService(nature=NatureOfService.DOMAIN)
> > public class MyApplicationUserFactory implements ApplicationUserFactory {
> >
> > @Override
> > public ApplicationUser newApplicationUser() {
> > final ApplicationUser object = new Person();
> > serviceRegistry.injectServicesInto(object);
> > return object;
> > }
> >
> > @javax.inject.Inject
> > RepositoryService repositoryService;
> > @javax.inject.Inject
> > ServiceRegistry2 serviceRegistry;
> > }
> >
> > Then to control what Organisation a person can see at any one time I
> have:
> >
> > @DomainService(nature = NatureOfService.DOMAIN)
> > public class TenancyPathEvaluatorForCooperation implements
> > ApplicationTenancyEvaluator {
> > @Override
> > public boolean handles(final Class cls) {
> > return Organisation.class == cls;
> > }
> >
> > @Override
> > public String disables(Object arg0, ApplicationUser arg1) {
> > return null;
> > }
> >
> > @Override
> > public String hides(Object arg0, ApplicationUser arg1) {
> > if (((Organisation) arg0).equals(((Person)
> > arg1).getOrganisation()))
> > return null;
> > else
> > return "Organisation access prevented";
> > }
> > }
> >
> >
> > Note: This has yet to be extended to handle all classes that are linked
> to
> > an Organisation!
> >
> > One thing I  have not done is to allow a user to switch their
> Organisation
> > context, this is simply done by presenting a list of Organisations based
> on
> > the list of OrganisationPerson entities that reference their Person
> entity,
> > which is what the security module returns as the logged in user. I think
> > this is how this should be accessed:
> >
> > Person user = (Person) userRepo.findByUsernameCached(
> &g

Re: Tenancy restriction - entity that relates to more than one Other entity.

[Patrick Pliessnig]

Hi Nikhil

I guess this ultimately relates to the question how a practice knows about
its patients and the related access path.

With tenancy the answer is: the patients are the ones with access rights
for the practice.

Maybe you could use a practice attribute 'practicePatients'. Then the
answer is: the patients are the ones that use the services of the practice.
(Many to many).

Patrick


Am 30.11.2017 12:58 nachm. schrieb "Nikhil Dhamapurkar" :

Hi,

I am working on supporting Multi Tenancy in Apache ISIS I have tried both
1) ApplicationTenancyEvaluator and 2) HasAtPath interfaces to control what
the  logged in user can see or execute.

I have been able to make them work to an acceptable state but I face issue
when I come across collections that are part of the entity I am evaluating.

My Domain model has Patient  / Practitioner entity both these entity can be
associated with Different Practices at the same time.


Example :PractitionerA belongs to PracticeA and PracticeB both, logged
in User has “Role” to Access PracticeA.

Issue with ApplicationTenancyEvaluator : since Practitioner and Practice
have many to many relation even if the role has access to only one practice
I’ll end up displaying PracticeB on wicket viewer which I want to prevent,
Is it possible ?


Issue with HasAtPath :

I am creating  Path programmatically with pattern as :
ORG/org/PRACTICE//  pattern which models a tree, then I can
control user access to more than one Patient data if user at path is
/ORG/org Or restrict  access to one practice  /ORG/org/PRACTICE/practiceA
If the Patient Entity is associated with more than one practice My logic
will Break as I would not know what should be the context for the for
ORG/org/PRACTICE/

Does anyone have a better solution to tackle tenancy for a Collection
within an entity?

Regards
Nikhil

Re: Nature of JAXB Views Models

[Patrick Pliessnig]

Perfect
Patrick

Am 20.10.2017 um 14:14 schrieb Dan Haywood:

Hi Patrick,

I agree, it should be possible to do what you want.  I've raised a ticket
[1] for it.

In the meantime, go with nature=VIEW_MODEL and add a TODO in your code to
update when we make the fix.

Thx
Dan

[1] https://issues.apache.org/jira/browse/ISIS-1749

On Fri, 20 Oct 2017 at 13:11 Patrick Pliessnig <p.pliess...@gmail.com>
wrote:


It passes validation effectively with nature = Nature.VIEW_MODEL
indicating (as much as I can see) that the view model belongs to the
application layer.

But using

 nature = Nature.INMEMORY_ENTITY or
 nature = Nature.EXTERNAL_ENTITY

to indicate that the view model is just a proxy for other domain objects
in the domain layer generates this validation error:

 ... has multiple incompatible annotations/interfaces indicating that
 it is a recreatable object of some sort
 (RecreatableObjectFacetForDomainObjectAnnotation and
 RecreatableObjectFacetForXmlRootElementAnnotation)

So, I don't know how to specify that a jaxb view model is - say - a
proxy for an external entity as I can do with legacy view models.



Am 20.10.2017 um 13:22 schrieb Jeroen van der Wal:

This is how I use it:

@DomainObject(nature = Nature.VIEW_MODEL, objectType = "MyJaxbViewModel")
@XmlRootElement(name = "myJaxbViewModel")
@XmlType(
  propOrder = {
  "myIncludedProperty"
  }
)
@XmlAccessorType(XmlAccessType.FIELD)
public class MyJaxbViewModel {

  @Getter @Setter @Nullable
  private String myIncludedProperty;

  @Getter @Setter @Nullable
  private String myIncludedProperty;

  @XmlTransient
  private String myExcludedProperty;

}

HTH


On 20 October 2017 at 12:28, Patrick Pliessnig <p.pliess...@gmx.net>

wrote:

Hi

Modeling a JAXB view model with @XmlRootElement and its nature with
@DomainObject( nature = ... ) does not pass metamodel validation.

Is there way to indicate the nature of a JAXB view model?
Eg. whether it belongs to the domain model or the application layer.

thx
Patrick

Re: Nature of JAXB Views Models

[Patrick Pliessnig]

It passes validation effectively with nature = Nature.VIEW_MODEL 
indicating (as much as I can see) that the view model belongs to the 
application layer.


But using

   nature = Nature.INMEMORY_ENTITY or
   nature = Nature.EXTERNAL_ENTITY

to indicate that the view model is just a proxy for other domain objects 
in the domain layer generates this validation error:


   ... has multiple incompatible annotations/interfaces indicating that
   it is a recreatable object of some sort
   (RecreatableObjectFacetForDomainObjectAnnotation and
   RecreatableObjectFacetForXmlRootElementAnnotation)

So, I don't know how to specify that a jaxb view model is - say - a 
proxy for an external entity as I can do with legacy view models.




Am 20.10.2017 um 13:22 schrieb Jeroen van der Wal:

This is how I use it:

@DomainObject(nature = Nature.VIEW_MODEL, objectType = "MyJaxbViewModel")
@XmlRootElement(name = "myJaxbViewModel")
@XmlType(
 propOrder = {
 "myIncludedProperty"
 }
)
@XmlAccessorType(XmlAccessType.FIELD)
public class MyJaxbViewModel {

 @Getter @Setter @Nullable
 private String myIncludedProperty;

 @Getter @Setter @Nullable
 private String myIncludedProperty;

 @XmlTransient
 private String myExcludedProperty;

}

HTH


On 20 October 2017 at 12:28, Patrick Pliessnig <p.pliess...@gmx.net> wrote:


Hi

Modeling a JAXB view model with @XmlRootElement and its nature with
@DomainObject( nature = ... ) does not pass metamodel validation.

Is there way to indicate the nature of a JAXB view model?
Eg. whether it belongs to the domain model or the application layer.

thx
Patrick

Quickstart with Embedded Camel generates HTTP ERROR 503

[Patrick Pliessnig]

Hi

I generate a Quickstart App and run it with 'mvn -pl webapp jetty:run'. 
Everything works fine.


I then uncomment the blocks between |'Uncomment to include example 
modules that set up embedded camel'| and run it again with 1) 'mvn clean 
install' 2) 'mvn -pl webapp jetty:run'. This time - on localhost:8080 - 
the browser generates a: HTTP ERROR 503 ( Service unavailable ).


If I boot it within the IDE with 'org.apache.isis.WebServer' everything 
works fine.


Do I miss something?

Thx
Patrick

Re: How to display value object

[Patrick Pliessnig]

Hey Kevin

What other behaviour has replaced ValueAdapters?

Cheers
Patrick


Am 15.08.2017 um 11:55 schrieb Kevin Meyer:

Hi Ekko,

I believe Dan has answered the question that you asked. However I think it
is worth mentioning that (as I see it), Apache Isis does not treat the
different objects in the way that I think you are considering them.

While DDD may make the distinction between "value" and "entity" e.g. [1],
in Apache Isis, all annotated objects are entities and persisted to the
database.

By annotating a "value" object e.g. in [2] with @PrimaryKey (and @Column),
you are declaring that that are to be persisted - that they are entities.

In your case "CustomerContactInfomation" is an entity. You just want to
subordinate maintenance and viewing to the Customer entity.

True DDD "value" objects (which are also immutable) would not be persisted
in their own table - there is no need and you'd fill up a table with old
entries that are no longer needed (the Location in the example [1]).
To me, the "immutable" aspect of a value object means that *if* you did
persist it to a table, you'd want to delete the old entry as soon as the
value changes or the reference count drops to zero.

In Apache Isis you would make them properties of the parent. It was once
possible to write ValueAdapters that could serialise a value class into
(one or more) columns of the table used to persist the "parent" entity and
the framework would maintain (serialise/deserialise) these "value" object
properties for you.
However these ValueAdapters are no longer supported (the behaviour is now
achieved in other ways).

In short - in Apache Isis all "database" annotated objects are entities.
But you can tweak the presentation of data from these entities with the
use of annotations and actions (on the "parent") to enforce the
subordination expected of a "value" object.

Cheers,
Kevin

[1] http://culttt.com/2014/04/30/difference-entities-value-objects/
[2] https://stackoverflow.com/a/45662839/56880


Hi support,


I'm building project with Apache Isis,but I have some confusion.


In DDD,I know there have two objects,entity & value object.


When I plan a DomainObject,eg. Customer, a entity object. I think one
Customer may be have many value objects,for example contact information
or other value objects.

So I plan a value object called CustomerContactInformation,may be have
other value objects.

For the database,a entity object and its value objects may be persist to
diff tables.

I think CustomerContactInformation just a value object,it can not have
any actions and should be maintained by Customer.

In fact,Customer-CustomerContactInfomation definitely is 1-1.


Now,how should I display CustomerContactInformation in Customer's layout
and be able to edit CustomerContactInformation?

Any ideas?


Ekko

task module

[Patrick Pliessnig]

Hello

I would like to have a look at the upcoming task module.
Is that possible? Where can I find it?

Thx
Patrick

Re: IsisCon2017 write-ups

[Patrick Pliessnig]

Thank you for setting this up Dan

On a first lecture I notice that there is consent that the audience for 
the pitch needs to have business expertise.

But why technical expertise?

Apache Isis' claim seems quite non-technical to me:

   the business expert reflects about a mental concept, the techy puts
   it 1 to 1 into the codebase and apache isis casts it to the screen,
   such that the business expert can admire and verify it.

   that's the loop.

astonishing enough. you maybe need a technical expert to validate the 
claim. for the pitch too?


Patrick


Am 16.06.2017 um 09:07 schrieb Dan Haywood:

Hi folks,

for those unable to make it to last weekends mini-conference we had in
Amsterdam, I've collated together all the material that's been provided
since, along with screenshots of the various notes we made along the way.

You'll find them on the wiki: [1]

If you were there (or even if you weren't) and have stuff to add or remark
upon, contributions always welcome.  If the outputs get too big for a
single page, I'll break it out, but for now I think it's nice to have it
all as a one-pager.

Cheers
Dan

[1] https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up

Re: IsisCon2017 write-ups

[Patrick Pliessnig]

Thank you for setting this up Dan

On a first lecture I notice that there is consent that the audience for 
the pitch needs to have business expertise.

But why technical expertise?

Apache Isis' claim seems quite non-technical to me:

   the business expert reflects about a mental concept, the techy puts
   it one to one into the codebase and apache isis casts it to the
   screen, such that the business expert can admire and verify it.

   that's the loop.

astonishing enough. you maybe need a technical expert to validate the 
claim. for the pitch too?


Patrick


Am 16.06.2017 um 09:07 schrieb Dan Haywood:

Hi folks,

for those unable to make it to last weekends mini-conference we had in
Amsterdam, I've collated together all the material that's been provided
since, along with screenshots of the various notes we made along the way.

You'll find them on the wiki: [1]

If you were there (or even if you weren't) and have stuff to add or remark
upon, contributions always welcome.  If the outputs get too big for a
single page, I'll break it out, but for now I think it's nice to have it
all as a one-pager.

Cheers
Dan

[1] https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up

Re: IsisCon 2017: Welcome Party / Video Testimonals

[Patrick Pliessnig]

Cool, thank you for organizing all this!

Say, you are biasing the story. What part then could possibly be biased? 
Openness? Honesty? Passion? Brilliance? Hmm ;-)



Am 05.06.2017 um 16:35 schrieb Jeroen van der Wal:

Dear all,

IsisCon is only a few days away and we're excited to have the right 
people at same time in one space again.


*Welcome party*

The welcome party on Friday will be held on a boat, courtesy of 
Eurocommercial Properties. We board around 5pm for a two hour canal 
tour and dock near a restaurant for dinner around 7pm. It's an open 
boat so it's advisable to bring a jacket, just in case it gets chilly.


*Video testimonials*

We've asked Jonathan Doornenbal, a young and talented film maker [1] 
to create short video testimonials of the users of Apache Isis, to be 
used on the Apache Isis website. The goal is to give the project a 
human face.


These testimonials are free format and are driven by the stories you 
want to share. Jonathan will ask some questions to start the 
conversation. We want to prevent it to be glossy and commercial so you 
could also share the imperfect sides. Important is that we communicate 
to potentials users what we are: the open, honest and passionate 
community behind a brilliant open source framework. Or am I biasing 
the story now? ;-)


We will use the Friday afternoon for these short interviews and 
perhaps do some more on Saturday. Above all, there is no obligation to 
participate in this but we really like to hear your stories.


See you all in Amsterdam!

Kind regards,

Dan, Johan & Jeroen


[1] http://www.jonathandoornenbal.com/ 

buildnumber-maven-plugin

[Patrick Pliessnig]

Hi

I run into problems when executing 'mvn validate' with 
simpleapp-archetype version 1.14.0 by following the documentation


The new mojo:buildnumber-mave-plugin generates the error message: 
"Cannot get the revision information from the scm repository"


Obviously this error makes sense as I was not connected to any scm 
during validation. To pass validation without connection to an scm, I 
added the plugin parameter  to the pom.xml in the 
webapp directory (See my plugin configuration below). This seems to work 
well so far.


Anyway I couldn't find any hint for that problem in the apache isis 
documentation.



org.codehaus.mojo
buildnumber-maven-plugin
1.4
...

true



Cheers
Patrick

Re: no setting to import in isis-settings-file-templates.jar

[Patrick Pliessnig]

perfect. thx

Patrick


Am 29.04.2016 um 13:33 schrieb Dan Haywood:

Hmm, I think this is a bug with IntelliJ 2016.

I've updated the docs with a workaround.

Cheers
Dan

http://isis.apache.org/guides/dg.html#_dg_ide_intellij_file-templates





On 29 April 2016 at 10:11, Dan Haywood <d...@haywood-associates.co.uk> wrote:


Hi Patrick,
I updated and tidied this stuff up recently (earlier this week, I think it
was), looks like I messed up somewhere.

Let me take a look

Thx
Dan

On 29 April 2016 at 10:08, Patrick Pliessnig <p.pliess...@gmx.net> wrote:


Hi

Following the Developers' Guide, I installed the latest version of
IntelliJ IDEA community edition 2016.1.1

I also downloaded isis-settings-file-templates.jar according to the guide.
(
https://isis.apache.org/guides/resources/appendices/dev-env/intellij/isis-settings-file-templates.jar
)

However the File > Import Settings command failed.
It didn't show no settings at all to import but should show one category
according to the guide.
The import of the live-templates and the code-style works as expected.

Is there a point I miss?

Thank you for your help.
Patrick