Re: Edit modes in Apache Isis

[Stephen Cameron]

Hi David,

This is a very interesting, getting back to the first principles. The idea
of a separate "tab through the fields type of thing" View Model to 'give
birth' to an object does make good sense to me, it fills that purpose and
that purpose only. The whole issue of 'edit mode' on a domain object and
what that should mean disappears as, as you suggest, the default view of a
domain object (in its nakedness) is largely behavioural.

Thanks

On Thu, May 26, 2016 at 7:02 AM, David Tildesley <
davo...@yahoo.co.nz.invalid> wrote:

> Hi,
> Just to add an architectural perspective - I think you are all right and
> all wrong at the same time ;).
> Dan is absolutely right if he constrains his comments to Domain Objects
> (which I believe is the case).
> I think the framework should enforce the Naked Object principles
> (which are in turn are an expression of sound architecture and OO
> principles and patterns) .  And that means no CRUD exposed in the UI
> directly from Domain Objects and for Domain Objects to be action/behaviour
> oriented.
> However in reference to the UI layer - then consider it disposable,
> evolving and changing with new views as need for specific use cases. That
> is precisely what the View Model is for in ISIS I believe.
> The domain layer (domain objects), provided the domain model was well
> designed in the first place, is mostly stable and easily extended over the
> lifecycle of the application.
> We can't stop developers from bleeding concerns across layers but we can
> do more  re-inforce the domain object/model and the rich domain pattern
> which is a reflection of the principle of separation of concerns and
> layering style.
> What it does mean though, is  that for many use cases, it is less likely
> that you will expose the domain objects directly and more likely you will
> use View Model (I hesitate to use the term View Object for obvious reasons)
> and View Model will call behaviour on the domain objects as needed.
> Which hopefully means that generated wicket UI/viewer behaviour from View
> Model source will move to provide what some folk are asking for - a rapid
> data input (tab through the fields type of thing). But not from domain
> objects.
> OK so it means that you need to deliberately layer your application by
> separating View and Domain concerns ... but that is a good thing in the
> long run of the life of your app is it not?
> ISIS doesn't make the NO paradigm mandatory - that was caused by the
> introduction of the view model - I think that is a good thing - provided
> that you understand that the view model is UI layer only and you shouldn't
> bleed domain behaviour into it.
> Regards,David.
>
>
>
> On Thursday, 26 May 2016 5:15 AM, Dan Haywood <
> d...@haywood-associates.co.uk> wrote:
>
>
>  Good input, thanks.
>
> My experience both with Estatio (4 years) but also with the big Naked
> Objects system in Ireland (12 years) is that actions only is good enough in
> the vast majority of cases ; and where bulk input is genuinely needed, then
> we can usually address it with a little lateral thinking.
>
> For Estatio, there's an occasional requirement to bulk upload new tax
> rates, and for that we use the isis-module-excel that allows the users to
> just upload an excel spreadsheet and process that.  Works quite well.
>
> The risk of allowing general free - form editing in ERP systems is that
> users are liable to abuse the freedom... we saw this for example in the
> packaged software that Estatio replaced... spare /unused fields end up
> being co-opted to store all sorts of adhoc info.  Instead, we should be
> exploiting the fact that Isis allows such rapid development by keeping
> things tight: relying on actions only means that the conversation as to
> *why* the data needs to change can be had, resulting in a richer ubiquitous
> language/insights/domain model.
>
> All that said, we'll continue to evolve and improve the default UI, and to
> make it easier to allow it to be extended for use cases such as this. One
> option is different UIs, or to use custom UIs based on the Restful viewer,
> but they are completely different experiences from an end-user
> perspective.  Another more seamless/smoother integration might be to
> leverage the nowicket framework which allows custom Wicket forms to be
> developed quite easily; we've been in touch with its developer, and have
> started spiking some things.
>
> Hope that helps explain some of the rationale a little better.
>
> Thanks,
> Dan
>
> http://invesdwin.de/nowicket/introduction
>
> Hello. I have to agree with Steve and Hector. In my experience creating
> and implementing ERP and large Merchandise Management systems, the
> ability to change all fields within a TAB combined with in-line row
> entry and editing is a must in a system where you handle a large volume
> of transactional data entry (we have been extensively using those
> features for the last 25 years or so in our systems, and the users
> strongly request 

Re: Context in apache isis

[Pedro Alba]

Dan,

I mean the context of the application.

The idea is the following:

We package the application using mvn package, where we get the war file the
application.

In this case we have the simpleapp.war file, which deployed in an
application server.

So far so good.

The wicket viewer works fine, however when we go to swagger-ui, the
application has the context / restful / * and the question is focused on
how we can set our Application context path in apache isis, so that the
layer API's REST has the context / SimpleApp / restful /, both the
swagger-ui, and resources set out in it suchas "restful / services /
ConfigurationServiceMenu" provided by apache isis.

Thank you for your time and cooperation, it´s invaluable.

2016-05-25 15:59 GMT-05:00 Dan Haywood :

> Which context? There are many...
> On 25 May 2016 9:58 pm, "Pedro Alba"  wrote:
>
> > Hi.
> > I could help with an explanation of how the context of an application is
> > changed in isis apache.
> >
> > Thank you.
> > --
> >
> > [image: Logo]
> >
> > *Pedro Antonio Alba *
> > *Senior Development Analyst*
> > Tel: (57) 1 703 17 77
> > Cel: (57) 301 3379810
> > E-mail: pedro.a...@ticxar.com
> > Calle 93 # 19b - 66 Ofc 202
> > Bogotá D.C., Colombia
> > www.ticxar.com
> >
> >
> >
> >   [image: facebook]
> >  [image:
> > twitter]  [image: linkedIn]
> > 
> >
>



-- 

[image: Logo]

*Pedro Antonio Alba *
*Senior Development Analyst*
Tel: (57) 1 703 17 77
Cel: (57) 301 3379810
E-mail: pedro.a...@ticxar.com
Calle 93 # 19b - 66 Ofc 202
Bogotá D.C., Colombia
www.ticxar.com



  [image: facebook]
 [image:
twitter]  [image: linkedIn]

Re: Edit modes in Apache Isis

[David Tildesley]

Hi,
Just to add an architectural perspective - I think you are all right and all 
wrong at the same time ;). 
Dan is absolutely right if he constrains his comments to Domain Objects (which 
I believe is the case).
I think the framework should enforce the Naked Object principles (which are in 
turn are an expression of sound architecture and OO principles and patterns) .  
And that means no CRUD exposed in the UI directly from Domain Objects and for 
Domain Objects to be action/behaviour oriented.
However in reference to the UI layer - then consider it disposable, evolving 
and changing with new views as need for specific use cases. That is precisely 
what the View Model is for in ISIS I believe.
The domain layer (domain objects), provided the domain model was well designed 
in the first place, is mostly stable and easily extended over the lifecycle of 
the application. 
We can't stop developers from bleeding concerns across layers but we can do 
more  re-inforce the domain object/model and the rich domain pattern which is a 
reflection of the principle of separation of concerns and layering style.
What it does mean though, is  that for many use cases, it is less likely that 
you will expose the domain objects directly and more likely you will use View 
Model (I hesitate to use the term View Object for obvious reasons) and View 
Model will call behaviour on the domain objects as needed.
Which hopefully means that generated wicket UI/viewer behaviour from View Model 
source will move to provide what some folk are asking for - a rapid data input 
(tab through the fields type of thing). But not from domain objects.
OK so it means that you need to deliberately layer your application by 
separating View and Domain concerns ... but that is a good thing in the long 
run of the life of your app is it not?
ISIS doesn't make the NO paradigm mandatory - that was caused by the 
introduction of the view model - I think that is a good thing - provided that 
you understand that the view model is UI layer only and you shouldn't bleed 
domain behaviour into it.
Regards,David.

 

On Thursday, 26 May 2016 5:15 AM, Dan Haywood 
 wrote:
 

 Good input, thanks.

My experience both with Estatio (4 years) but also with the big Naked
Objects system in Ireland (12 years) is that actions only is good enough in
the vast majority of cases ; and where bulk input is genuinely needed, then
we can usually address it with a little lateral thinking.

For Estatio, there's an occasional requirement to bulk upload new tax
rates, and for that we use the isis-module-excel that allows the users to
just upload an excel spreadsheet and process that.  Works quite well.

The risk of allowing general free - form editing in ERP systems is that
users are liable to abuse the freedom... we saw this for example in the
packaged software that Estatio replaced... spare /unused fields end up
being co-opted to store all sorts of adhoc info.  Instead, we should be
exploiting the fact that Isis allows such rapid development by keeping
things tight: relying on actions only means that the conversation as to
*why* the data needs to change can be had, resulting in a richer ubiquitous
language/insights/domain model.

All that said, we'll continue to evolve and improve the default UI, and to
make it easier to allow it to be extended for use cases such as this. One
option is different UIs, or to use custom UIs based on the Restful viewer,
but they are completely different experiences from an end-user
perspective.  Another more seamless/smoother integration might be to
leverage the nowicket framework which allows custom Wicket forms to be
developed quite easily; we've been in touch with its developer, and have
started spiking some things.

Hope that helps explain some of the rationale a little better.

Thanks,
Dan

http://invesdwin.de/nowicket/introduction

Hello. I have to agree with Steve and Hector. In my experience creating
and implementing ERP and large Merchandise Management systems, the
ability to change all fields within a TAB combined with in-line row
entry and editing is a must in a system where you handle a large volume
of transactional data entry (we have been extensively using those
features for the last 25 years or so in our systems, and the users
strongly request them). As an example use case, a user must enter
sometimes tens or even hundreds of rows (a purchase order line item
detail, a price change batch line item, journal entries and so on). Just
try doing that using the mouse and going back and forth on each row.
Luckily in our current applications we are building with Apache ISIS, we
are managing most of the data entry on the mobile devices, which handle
this in-line editing and all form editing easily, leveraging the amazing
ISIS capability to create web services from actions. But we do not see
us using the current Isis forms for that a system where there is volume
data entry in the browser. Having the ISIS ability 

Re: Context in apache isis

[Dan Haywood]

Which context? There are many...
On 25 May 2016 9:58 pm, "Pedro Alba"  wrote:

> Hi.
> I could help with an explanation of how the context of an application is
> changed in isis apache.
>
> Thank you.
> --
>
> [image: Logo]
>
> *Pedro Antonio Alba *
> *Senior Development Analyst*
> Tel: (57) 1 703 17 77
> Cel: (57) 301 3379810
> E-mail: pedro.a...@ticxar.com
> Calle 93 # 19b - 66 Ofc 202
> Bogotá D.C., Colombia
> www.ticxar.com
>
>
>
>   [image: facebook]
>  [image:
> twitter]  [image: linkedIn]
> 
>

Re: Edit modes in Apache Isis

[César Camilo Lugo Marcos]

Dan,

After a quick look, I can see why you are considering nowicket. I particularly 
like these features:

- DDD and NO incorporated too. In line with ISIS.
- Keep the automatic generation of forms from model ISIS concept.
- You customize forms by using HTML, instead of a domain specific language or 
markup language, even using a WYSIWYG editor. If rebuilding a form, you don't 
loose the changes you made to it, changes are merged.
- You can use anything Wicket supports (that includes mutable in-line editing. 
I saw a couple of examples in the Wicket Examples Rebuilt" section, Ajax 
Datatable and Form Input).
- I guess in the ISIS integration you might be able to maintain the ability to 
group actions with properties editing in those cases where it makes sense.

Sounds promising.

Cesar.

On Wed, 2016-05-25 at 18:15 +0100, Dan Haywood


Good input, thanks.

My experience both with Estatio (4 years) but also with the big Naked
Objects system in Ireland (12 years) is that actions only is good enough in
the vast majority of cases ; and where bulk input is genuinely needed, then
we can usually address it with a little lateral thinking.

For Estatio, there's an occasional requirement to bulk upload new tax
rates, and for that we use the isis-module-excel that allows the users to
just upload an excel spreadsheet and process that.  Works quite well.

The risk of allowing general free - form editing in ERP systems is that
users are liable to abuse the freedom... we saw this for example in the
packaged software that Estatio replaced... spare /unused fields end up
being co-opted to store all sorts of adhoc info.  Instead, we should be
exploiting the fact that Isis allows such rapid development by keeping
things tight: relying on actions only means that the conversation as to
*why* the data needs to change can be had, resulting in a richer ubiquitous
language/insights/domain model.

All that said, we'll continue to evolve and improve the default UI, and to
make it easier to allow it to be extended for use cases such as this. One
option is different UIs, or to use custom UIs based on the Restful viewer,
but they are completely different experiences from an end-user
perspective.  Another more seamless/smoother integration might be to
leverage the nowicket framework which allows custom Wicket forms to be
developed quite easily; we've been in touch with its developer, and have
started spiking some things.

Hope that helps explain some of the rationale a little better.

Thanks,
Dan

http://invesdwin.de/nowicket/introduction

Hello. I have to agree with Steve and Hector. In my experience creating
and implementing ERP and large Merchandise Management systems, the
ability to change all fields within a TAB combined with in-line row
entry and editing is a must in a system where you handle a large volume
of transactional data entry (we have been extensively using those
features for the last 25 years or so in our systems, and the users
strongly request them). As an example use case, a user must enter
sometimes tens or even hundreds of rows (a purchase order line item
detail, a price change batch line item, journal entries and so on). Just
try doing that using the mouse and going back and forth on each row.
Luckily in our current applications we are building with Apache ISIS, we
are managing most of the data entry on the mobile devices, which handle
this in-line editing and all form editing easily, leveraging the amazing
ISIS capability to create web services from actions. But we do not see
us using the current Isis forms for that a system where there is volume
data entry in the browser. Having the ISIS ability to associate actions
to enter a group of fields / properties together and trigger some action
is beautiful, but I do not think it should replace all form editing nor
in-line row entry and editing, but they can both work as a complement.

I've heard from Dan that ISIS will have additional viewer options in the
future as a result of its open hexagonal architecture and some join
efforts with the NakedObjects guys, which sounds great!. I hope they
might bring us some UI friendly features like those. I recognize there
have been some recent significant improvements to the UI configuration,
and hope there will be in-line row entry and editing and back to all
form / all TAB editing soon.

Cesar.

On Wed, 2016-05-25 at 05:14 +, Dan Haywood wrote:
> Well, editing is enabled by default, so CRUD is supported.  We certainly
> don't want to make the framework deliberately difficult to use.
>
> I think the best thing for me to say is that editing properties is a
> work-in-progress, and where we're aiming to get to is a JIRA-like
> look-n-feel.  If it works well enough for that app, then I think it should
> suffice for Isis too.
>
> Thx
> Dan
>
>
>
> On 25 May 2016 at 03:36, Stephen Cameron 
> >
wrote:
>
> > I know this has been discussed previously, but it seems such a 

Context in apache isis

[Pedro Alba]

Hi.
I could help with an explanation of how the context of an application is
changed in isis apache.

Thank you.
-- 

[image: Logo]

*Pedro Antonio Alba *
*Senior Development Analyst*
Tel: (57) 1 703 17 77
Cel: (57) 301 3379810
E-mail: pedro.a...@ticxar.com
Calle 93 # 19b - 66 Ofc 202
Bogotá D.C., Colombia
www.ticxar.com



  [image: facebook]
 [image:
twitter]  [image: linkedIn]

Re: Edit modes in Apache Isis

[Dan Haywood]

Good input, thanks.

My experience both with Estatio (4 years) but also with the big Naked
Objects system in Ireland (12 years) is that actions only is good enough in
the vast majority of cases ; and where bulk input is genuinely needed, then
we can usually address it with a little lateral thinking.

For Estatio, there's an occasional requirement to bulk upload new tax
rates, and for that we use the isis-module-excel that allows the users to
just upload an excel spreadsheet and process that.  Works quite well.

The risk of allowing general free - form editing in ERP systems is that
users are liable to abuse the freedom... we saw this for example in the
packaged software that Estatio replaced... spare /unused fields end up
being co-opted to store all sorts of adhoc info.  Instead, we should be
exploiting the fact that Isis allows such rapid development by keeping
things tight: relying on actions only means that the conversation as to
*why* the data needs to change can be had, resulting in a richer ubiquitous
language/insights/domain model.

All that said, we'll continue to evolve and improve the default UI, and to
make it easier to allow it to be extended for use cases such as this. One
option is different UIs, or to use custom UIs based on the Restful viewer,
but they are completely different experiences from an end-user
perspective.  Another more seamless/smoother integration might be to
leverage the nowicket framework which allows custom Wicket forms to be
developed quite easily; we've been in touch with its developer, and have
started spiking some things.

Hope that helps explain some of the rationale a little better.

Thanks,
Dan

http://invesdwin.de/nowicket/introduction

Hello. I have to agree with Steve and Hector. In my experience creating
and implementing ERP and large Merchandise Management systems, the
ability to change all fields within a TAB combined with in-line row
entry and editing is a must in a system where you handle a large volume
of transactional data entry (we have been extensively using those
features for the last 25 years or so in our systems, and the users
strongly request them). As an example use case, a user must enter
sometimes tens or even hundreds of rows (a purchase order line item
detail, a price change batch line item, journal entries and so on). Just
try doing that using the mouse and going back and forth on each row.
Luckily in our current applications we are building with Apache ISIS, we
are managing most of the data entry on the mobile devices, which handle
this in-line editing and all form editing easily, leveraging the amazing
ISIS capability to create web services from actions. But we do not see
us using the current Isis forms for that a system where there is volume
data entry in the browser. Having the ISIS ability to associate actions
to enter a group of fields / properties together and trigger some action
is beautiful, but I do not think it should replace all form editing nor
in-line row entry and editing, but they can both work as a complement.

I've heard from Dan that ISIS will have additional viewer options in the
future as a result of its open hexagonal architecture and some join
efforts with the NakedObjects guys, which sounds great!. I hope they
might bring us some UI friendly features like those. I recognize there
have been some recent significant improvements to the UI configuration,
and hope there will be in-line row entry and editing and back to all
form / all TAB editing soon.

Cesar.

On Wed, 2016-05-25 at 05:14 +, Dan Haywood wrote:
> Well, editing is enabled by default, so CRUD is supported.  We certainly
> don't want to make the framework deliberately difficult to use.
>
> I think the best thing for me to say is that editing properties is a
> work-in-progress, and where we're aiming to get to is a JIRA-like
> look-n-feel.  If it works well enough for that app, then I think it should
> suffice for Isis too.
>
> Thx
> Dan
>
>
>
> On 25 May 2016 at 03:36, Stephen Cameron 
wrote:
>
> > I know this has been discussed previously, but it seems such a central
> > thing that I have to add my two-bits worth again.
> >
> > Re: "it positions the framework away from the common perception of it
being
> > a CRUD framework;"
> >
> > Any database application is at its core a CRUD application, unless its
view
> > only. So the key thing, surely, is to show people how much more Isis
can do
> > and how easily. It seems you want to be deliberately unfamiliar to
users in
> > order to show that its different to those other 'CRUD in five minutes'
> > frameworks.
> >
> > Making a group of properties read-only and providing an action to update
> > all the properties together is a useful pattern, but you seem to be
> > suggesting that this is the right way to do it everywhere because
Estatio
> > is done that way.
> >
> > I think the in-situ editing will be good as a default behaviour.
> >
> > On the upside, I think Isis is now a very sweet 

Re: Edit modes in Apache Isis

[César Camilo Lugo Marcos]

Hello. I have to agree with Steve and Hector. In my experience creating
and implementing ERP and large Merchandise Management systems, the
ability to change all fields within a TAB combined with in-line row
entry and editing is a must in a system where you handle a large volume
of transactional data entry (we have been extensively using those
features for the last 25 years or so in our systems, and the users
strongly request them). As an example use case, a user must enter
sometimes tens or even hundreds of rows (a purchase order line item
detail, a price change batch line item, journal entries and so on). Just
try doing that using the mouse and going back and forth on each row.
Luckily in our current applications we are building with Apache ISIS, we
are managing most of the data entry on the mobile devices, which handle
this in-line editing and all form editing easily, leveraging the amazing
ISIS capability to create web services from actions. But we do not see
us using the current Isis forms for that a system where there is volume
data entry in the browser. Having the ISIS ability to associate actions
to enter a group of fields / properties together and trigger some action
is beautiful, but I do not think it should replace all form editing nor
in-line row entry and editing, but they can both work as a complement.

I've heard from Dan that ISIS will have additional viewer options in the
future as a result of its open hexagonal architecture and some join
efforts with the NakedObjects guys, which sounds great!. I hope they
might bring us some UI friendly features like those. I recognize there
have been some recent significant improvements to the UI configuration,
and hope there will be in-line row entry and editing and back to all
form / all TAB editing soon.

Cesar.

On Wed, 2016-05-25 at 05:14 +, Dan Haywood wrote:
> Well, editing is enabled by default, so CRUD is supported.  We certainly
> don't want to make the framework deliberately difficult to use.
> 
> I think the best thing for me to say is that editing properties is a
> work-in-progress, and where we're aiming to get to is a JIRA-like
> look-n-feel.  If it works well enough for that app, then I think it should
> suffice for Isis too.
> 
> Thx
> Dan
> 
> 
> 
> On 25 May 2016 at 03:36, Stephen Cameron  wrote:
> 
> > I know this has been discussed previously, but it seems such a central
> > thing that I have to add my two-bits worth again.
> >
> > Re: "it positions the framework away from the common perception of it being
> > a CRUD framework;"
> >
> > Any database application is at its core a CRUD application, unless its view
> > only. So the key thing, surely, is to show people how much more Isis can do
> > and how easily. It seems you want to be deliberately unfamiliar to users in
> > order to show that its different to those other 'CRUD in five minutes'
> > frameworks.
> >
> > Making a group of properties read-only and providing an action to update
> > all the properties together is a useful pattern, but you seem to be
> > suggesting that this is the right way to do it everywhere because Estatio
> > is done that way.
> >
> > I think the in-situ editing will be good as a default behaviour.
> >
> > On the upside, I think Isis is now a very sweet framework to use in many,
> > many aspects. There is still alot for me to learn, but I am keen to do
> > that, and try to convince others of its merits too.
> >
> > Cheers
> > Steve
> >
> >
> >
> >
> >
> > On Tue, May 24, 2016 at 4:00 PM, Dan Haywood  > >
> > wrote:
> >
> > > Hi Hector,
> > > welcome to the users@ mailing list.
> > >
> > > I'm afraid that there isn't a setting to go back to the previous
> > behaviour,
> > > but there are some good reasons - some practical, some more
> > philosophical -
> > > why this change has been made.
> > >
> > > The practical reason is that with tabs, it's not particularly clear what
> > a
> > > global edit should be... should it be for all properties, including those
> > > not visible on other tabs?  or should it somehow disable being able to
> > > switch tabs when in edit mode? or perhaps there should be not a global
> > edit
> > > but instead an edit per fieldset/member group?  It wasn't at all clear
> > > which was preferable.
> > >
> > > Second, we've had a ticket knocking around for a while to move editing
> > > towards that in JIRA, where one clicks in the field and then can do an
> > > in-situ edit.  The current implementation isn't quite a slick as that,
> > but
> > > the number of clicks is actually the same.
> > >
> > > The philosophical reason is that, actually, it positions the framework
> > away
> > > from the common perception of it being a CRUD framework; instead it is
> > also
> > > for (even mostly for) complex domains where the is significant business
> > > logic to transition from one state of the system to another.  When Jeroen
> > > was implementing Estatio [1] he deliberately made 

Re: AW: jira access

[Stephen Cameron]

thanks Joerg



On Wed, May 25, 2016 at 9:21 PM, Dan Haywood 
wrote:

> Thanks for checking this out, Joerg.
>
> Cheers,
> Dan
> On 25 May 2016 08:41, "Rade, Joerg / Kuehne + Nagel / Ham GI-DP" <
> joerg.r...@kuehne-nagel.com> wrote:
>
> > I just logged in successfully.
> >
> > There is 'a' red GUI element labeled "Create | v" which actually consists
> > of a Button 'Create' and a Dropdown 'v'.
> > Both have their own set of actions.
> >
> > You have to press the Button when you want to raise an issue.
> >
> > I recall that I was puzzled with this design as well ...
> >
> > HTH -j
> >
> > -Ursprüngliche Nachricht-
> > Von: Dan Haywood [mailto:d...@haywood-associates.co.uk]
> > Gesendet: Mittwoch, 25. Mai 2016 07:09
> > An: users
> > Betreff: Re: jira access
> >
> > Not sure.  I know that the ASF infra people have on occasion locked down
> > JIRA to prevent spam attacks, I saw a note about that a week ago.
> > Everything is reported ok on http://status.apache.org/
> >
> > I just created a brand new JIRA account for myself, without any committer
> > permissions etc, and was able to log in using that.  The ISIS project is
> > there as usual.  So I'm not sure what to advise ... "works for me".
> >
> > Is anyone else having issues still?
> >
> > Thx
> > Dan
> >
> >
> > On 25 May 2016 at 02:25, Stephen Cameron 
> > wrote:
> >
> > > Hi,
> > >
> > > I cannot create a Jira issue at present. When I try I see a list of 4
> > > projects that mean nothing to me.
> > >
> > > I've not been able to log anything against Apache Isis for more than a
> > > week, does anyone know what is going on?
> > >
> > > Thanks
> > >
> >
> > Kühne + Nagel (AG & Co.) KG
> > Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE
> > 812773878.
> > Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Reiner Heiken (Vors.),
> > Martin Brinkmann, Matthias Heimbach, Jan-Hendrik Köstergarten, Nicholas
> > Minde, Michael Nebel, Lars Wedel, Jens Wollesen.
> > Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform:
> > Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745,
> > Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
> > Geschäftsleitung Region Westeuropa: Yngve Ruud (Vors.), Diederick de
> > Vroet, Dominic Edmonds, Uwe Hött, Richard Huhn, Björn Johansson, Holger
> > Ketz, Jan Kunze.
> >
> > Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen
> > Spediteurbedingungen 2016 (ADSp 2016). Die ADSp 2016 beschränken in
> Ziffer
> > 23 die gesetzliche Haftung für Güterschäden in Höhe von 8,33 SZR/kg je
> > Schadenfall bzw. je Schadenereignis auf 1 Million bzw. 2 Millionen Euro
> > oder 2 SZR/kg, je nachdem, welcher Betrag höher ist, und bei multimodalen
> > Transporten unter Einschluss einer Seebeförderung generell auf 2 SZR/kg.
> > Den vollständigen Text der ADSp 2016 übersenden wir Ihnen gerne auf
> Anfrage
> > und können Sie auch unter http://www.kuehne-nagel.com einsehen.
> >
>

Re: AW: jira access

[Dan Haywood]

Thanks for checking this out, Joerg.

Cheers,
Dan
On 25 May 2016 08:41, "Rade, Joerg / Kuehne + Nagel / Ham GI-DP" <
joerg.r...@kuehne-nagel.com> wrote:

> I just logged in successfully.
>
> There is 'a' red GUI element labeled "Create | v" which actually consists
> of a Button 'Create' and a Dropdown 'v'.
> Both have their own set of actions.
>
> You have to press the Button when you want to raise an issue.
>
> I recall that I was puzzled with this design as well ...
>
> HTH -j
>
> -Ursprüngliche Nachricht-
> Von: Dan Haywood [mailto:d...@haywood-associates.co.uk]
> Gesendet: Mittwoch, 25. Mai 2016 07:09
> An: users
> Betreff: Re: jira access
>
> Not sure.  I know that the ASF infra people have on occasion locked down
> JIRA to prevent spam attacks, I saw a note about that a week ago.
> Everything is reported ok on http://status.apache.org/
>
> I just created a brand new JIRA account for myself, without any committer
> permissions etc, and was able to log in using that.  The ISIS project is
> there as usual.  So I'm not sure what to advise ... "works for me".
>
> Is anyone else having issues still?
>
> Thx
> Dan
>
>
> On 25 May 2016 at 02:25, Stephen Cameron 
> wrote:
>
> > Hi,
> >
> > I cannot create a Jira issue at present. When I try I see a list of 4
> > projects that mean nothing to me.
> >
> > I've not been able to log anything against Apache Isis for more than a
> > week, does anyone know what is going on?
> >
> > Thanks
> >
>
> Kühne + Nagel (AG & Co.) KG
> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE
> 812773878.
> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Reiner Heiken (Vors.),
> Martin Brinkmann, Matthias Heimbach, Jan-Hendrik Köstergarten, Nicholas
> Minde, Michael Nebel, Lars Wedel, Jens Wollesen.
> Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform:
> Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745,
> Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
> Geschäftsleitung Region Westeuropa: Yngve Ruud (Vors.), Diederick de
> Vroet, Dominic Edmonds, Uwe Hött, Richard Huhn, Björn Johansson, Holger
> Ketz, Jan Kunze.
>
> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen
> Spediteurbedingungen 2016 (ADSp 2016). Die ADSp 2016 beschränken in Ziffer
> 23 die gesetzliche Haftung für Güterschäden in Höhe von 8,33 SZR/kg je
> Schadenfall bzw. je Schadenereignis auf 1 Million bzw. 2 Millionen Euro
> oder 2 SZR/kg, je nachdem, welcher Betrag höher ist, und bei multimodalen
> Transporten unter Einschluss einer Seebeförderung generell auf 2 SZR/kg.
> Den vollständigen Text der ADSp 2016 übersenden wir Ihnen gerne auf Anfrage
> und können Sie auch unter http://www.kuehne-nagel.com einsehen.
>

Re: i18n question

[Deacon Frost]

Thanks a lot for the explanation and links, Dan. I think I understand this
a bit better now (missed the fact that there needs to be an additional
properties-file for the component-html file etc. -- complete wicket "noob"
here). As soon as I am "geared up" for github-pull requests I hope I can
contribute to fixing minor quirks like hardcoded strings and the like...

Cheers,
Deacon

On Tue, May 24, 2016 at 9:21 AM, Dan Haywood 
wrote:

> Hmm, it would seem to be hard-coded [1].
>
> Elsewhere in the Wicket UI we allow i18n, eg of the "OK" and "Cancel"
> buttons [2], through a custom implementation of Wicket's Localizer SPI
> [3].  So it ought to be possible to i18n the "Show All" similarly.
>
> If you want to tackle this and raise a PR, that'd be great.  Otherwise I'll
> see if I can implement it in the next couple of days.
>
> Thx
> Dan
>
>
>
> [1]
>
> https://github.com/apache/isis/blob/rel/isis-1.12.1/core/viewer-wicket-ui/src/main/java/org/apache/isis/viewer/wicket/ui/components/collectioncontents/ajaxtable/IsisAjaxNavigationToolbar.html#L23
> [2]
>
> https://github.com/apache/isis/blob/rel/isis-1.12.1/core/viewer-wicket-ui/src/main/java/org/apache/isis/viewer/wicket/ui/components/actions/ActionParametersFormPanel.java#L144
> [3]
>
> https://github.com/apache/isis/blob/rel/isis-1.12.1/core/viewer-wicket-impl/src/main/java/org/apache/isis/viewer/wicket/viewer/integration/wicket/LocalizerForIsis.java#L52
> [4]
>
> https://github.com/apache/isis/blob/rel/isis-1.12.1/core/viewer-wicket-ui/src/main/java/org/apache/isis/viewer/wicket/ui/components/collectioncontents/ajaxtable/IsisAjaxNavigationToolbar.java#L44
>
>
> On 23 May 2016 at 14:41, Deacon Frost  wrote:
>
> > Hi,
> >
> > I'm trying to wrap my head around the translation feature and I'd like to
> > translate the "SHOW ALL"-label for the table paginator (ISIS-690). I
> can't
> > figure out the pot-address-string/msgid to translate this. Any hint how
> to
> > go about this?
> > Thanks a lot!
> >
> > Cheers,
> >
> > D.
> >
>

AW: jira access

[Rade, Joerg / Kuehne + Nagel / Ham GI-DP]

I just logged in successfully.

There is 'a' red GUI element labeled "Create | v" which actually consists of a 
Button 'Create' and a Dropdown 'v'.
Both have their own set of actions.

You have to press the Button when you want to raise an issue.

I recall that I was puzzled with this design as well ...

HTH -j

-Ursprüngliche Nachricht-
Von: Dan Haywood [mailto:d...@haywood-associates.co.uk]
Gesendet: Mittwoch, 25. Mai 2016 07:09
An: users
Betreff: Re: jira access

Not sure.  I know that the ASF infra people have on occasion locked down JIRA 
to prevent spam attacks, I saw a note about that a week ago.
Everything is reported ok on http://status.apache.org/

I just created a brand new JIRA account for myself, without any committer 
permissions etc, and was able to log in using that.  The ISIS project is there 
as usual.  So I'm not sure what to advise ... "works for me".

Is anyone else having issues still?

Thx
Dan


On 25 May 2016 at 02:25, Stephen Cameron  wrote:

> Hi,
>
> I cannot create a Jira issue at present. When I try I see a list of 4
> projects that mean nothing to me.
>
> I've not been able to log anything against Apache Isis for more than a
> week, does anyone know what is going on?
>
> Thanks
>

Kühne + Nagel (AG & Co.) KG
Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE 812773878.
Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Reiner Heiken (Vors.), Martin 
Brinkmann, Matthias Heimbach, Jan-Hendrik Köstergarten, Nicholas Minde, Michael 
Nebel, Lars Wedel, Jens Wollesen.
Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: 
Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, 
Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
Geschäftsleitung Region Westeuropa: Yngve Ruud (Vors.), Diederick de Vroet, 
Dominic Edmonds, Uwe Hött, Richard Huhn, Björn Johansson, Holger Ketz, Jan 
Kunze.

Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen 
Spediteurbedingungen 2016 (ADSp 2016). Die ADSp 2016 beschränken in Ziffer 23 
die gesetzliche Haftung für Güterschäden in Höhe von 8,33 SZR/kg je Schadenfall 
bzw. je Schadenereignis auf 1 Million bzw. 2 Millionen Euro oder 2 SZR/kg, je 
nachdem, welcher Betrag höher ist, und bei multimodalen Transporten unter 
Einschluss einer Seebeförderung generell auf 2 SZR/kg. Den vollständigen Text 
der ADSp 2016 übersenden wir Ihnen gerne auf Anfrage und können Sie auch unter 
http://www.kuehne-nagel.com einsehen.