Simple and clear. I like it. :-))
But not sure if on the provided example the viewer would prevent to navigate to
the newly created one.
I would expect the "logic" to be the next one:
1. Verify if the action is annotated with @NotNavigate or @Navigate. If so,
execute that behavior (as it's exp
@NotNagivate is indeed a better term. But if we use @AggregateRoot as
default behavior we also need a directive to excplicity move away from the
aggregate:
@AggregateRoot
public class Invoice {
...
public Invoice creditThisInvoice() {
// The @AR annotation prevents the viewer going
This is a mixed approach and I would prefer it also.
The viewer annotation @Void (if it's for the viewer, perhaps @NotNavigate or
something more specific or explicit would be better than the generic term
"void" ) would have preference on the viewer's behavior.
In absence, the logic could be to
I also prefer an annotation and not put boilerplate code in the domain for
ui purposes. An @AggregateRoot annotation doesn't meet all our requirements
though: we have cases where child objects are an aggregate in it's own:
Lease <- @AggregateRoot
+ LeaseItem <- aggregate for terms
+ LeaseTerm
Hi, Dan.
I like a lot the idea of explicitly having an annotation for Aggregate Roots
(and, "commercially" speaking, it can be a big call to all those interested on
DDD...). I'm sure we will find more use cases for that annotation in the near
future, as it will force us to consider the distinc
That's an interesting idea, Oscar.
The issue arises from the fact that there are potentially two different
callers of the Order#createItem method:
a) the Isis framework itself - in which case, as we all know, the signature
of the methdo is used to determine presentation/navigation
b) other domain
Really well-looking, Jeroen.
Regarding navigability through actions, I think that perhaps there are 2
distinct use cases that should be treated differently as such:
1. The user creates an Aggregate Root (such as an Order). As such, normally
want to navigate to the newly created one.
2. The use
Thanks for reminding Dan, screenshot now as link [1]
[1]
https://dl.dropboxusercontent.com/u/1930710/Attachments/Screen%20Shot%202013-12-02%20at%2010.03.35%20PM.png
On Mon, Dec 2, 2013 at 10:23 PM, Dan Haywood
wrote:
> Hi Jeroen,
> Screenshots get stripped from the mailing list, so you'll need
Hi Jeroen,
Screenshots get stripped from the mailing list, so you'll need to post it
somewhere online. How about updating the screenshots on Estatio's README?
By the way, I have a further commit... discovered that default values for
parameters are not honoured second time around (ie bring up an a
The modal dialog really improves the usability, thanks Dan. I've attached
attached a screenshot which tells more then thousand words.
I just recently learned that you can use java.lang.Object as the return
type of an action and return whatever domain object or collection you
programmatically decid
Good done.
We also use modal dialogs on our custom viewer to avoid context switching. The
same dialog redirects to a Domain Object if that's the result of the action
invocation, or currently shows a Collection in a grid on the same dialog if
that's the result of the action. The user can then
Hi folks,
just an fyi that I've committed and pushed ISIS-486 [1], to render the
Wicket viewer's action prompts in modal dialogs. This should make for a
better overall user experience.
To use, you'll need to build from source, as per [2].
In case there are issues, the old behaviour (action pro
12 matches
Mail list logo
