Re: changes behavior from 1.4.15 to 1.4.19 ?

[smallufo]

sorry for disturbance

after adding the 2 lines in Application , it's solved.

getResourceSettings().setParentFolderPlaceholder("$up$");
  getResourceSettings().addResourceFolder(getServletContext().getContextPath
());


2012/2/12 smallufo 

> 
> 
>
> This code works fine in wicket 1.4.15 , and will generate a url like this :
>
>
> http://foobar.com/app/resources/foobar.login.LoginPanel/null/icons/facebookLogin_300_35.png
>
> The "null" in URL seems represents ".." in the resource path.
>
> But when I upgrade to 1.4.19 , the URL becomes :
>
> http://foobar.com/app/resources/icons/facebookLogin_300_35.png
>
>
> It is broken !!!
>
> Why ? And ... how to fix it ? (without hardcode the path in java code)
>
>
>

Re: AjaxTabbedPanel - Enable / Disable Individual Tab.

[Francois Meillet]

you can override the newLink method in the TabbedPanel 


François


Le 12 févr. 2012 à 01:53, ej595 a écrit :

> Does anyone know how to enable or disable a Tab from a tabbedpanel. I dont
> mean visible or invisible. I want to be able to show all tabs, but disable
> the user from being able to click and view the tab contents until some
> condition i determine has been met. I can do it for the entire tab group,
> but thats not what i want. 
> 
> Anyone does anything like this ?
> 
> appreciate it.
> 
> 
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/AjaxTabbedPanel-Enable-Disable-Individual-Tab-tp4380339p4380339.html
> Sent from the Users forum mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Architectural question

[Bas Gooren]

Hi All,

I have an architectural question about wicket, DDD and the service layer.

Let's say we have a simple JPA entity (Customer), and a few simple CRUDL 
screens.
For database access, we have a DAO layer (CustomerDao) which delegates 
to an EntityManager, and provides some convenience methods for searching.
We also like to have clear boundaries, so we have a thin service layer 
which wraps persist() and delete() calls in a transaction before 
forwarding them to the DAO layer (@Transactional, as provided by 
guice-persist).


A wicket model fetches one or more customers (by id or by running a 
search), and attaches to a form. In the form we use PropertyModels which 
push their changes to the entity, and in onSubmit() we call 
service.persist(entity).
This means that the actual changes to the model happen outside of the 
transaction (in wicket code), and within the transaction (/service 
layer) we merely call persist() and flush().


Then parts of the app need something a bit more advanced, so we decide 
to apply parts of DDD and put logic where it belongs (on the domain 
models). However, some logic coordinates multiple models, so we add a 
domain- or application-service for that.
The good thing about DDD is that it's a lot more clear what happens 
(intent). We now realize that having a persist() method on a 
entity-based service now looks like a bit of a code smell, since it does 
not capture intent at all. Also, since the changes to the model happen 
in wicket, before the service layer is called, I feel that the service 
layer is not doing anything to act as a boundary. We might as well mark 
the persist() method on our daos @transactional and remove the service 
layer.


The only clean way to fix this seems to be either:
(a) using DTO's so the UI/wicket is not actually modifying domain entities
upside: the state of the domain is not modified by wicket itself
downside: duplication of models (actual model + DTO);
downside: validation is currently set-up in wicket by scanning 
fields for validation annotations, so we would need to duplicate those 
on the DTO?


(b) using a concept from CQRS: sending commands to the domain through a 
bus. This clearly and cleanly defines the intent and captures the exact 
change.

upside: the state of the domain is not modified by wicket itself
downside: likely overkill for what we are trying to achieve; lot of 
extra complexity


(c) wrapping the entire request in a transaction
upside: easy to implement
downside: since anything in the request can fetch a dao, read some 
entities and modify them, this means we can lose track of what happens 
in a request;

downside: feels like moving backwards

(d) simplify by removing thin services and, where necessary, putting 
more logic in the dao's
upside: simple api contract: want to save/update an entity? use the 
dao directly

downside: dao's contain logic which does not really belong there
downside: if at some point we really do need a service, the api 
contract becomes less clear: for X and Y you can use the dao, for Z you 
have to use a service


(a) and (b) provide a way to capture a change and execute all of the 
change inside a transaction.


So my question to the list is: what are your experiences with this? How 
do you deal with this in simple to moderately complex webapps?


Thanks for reading!

Re: Architectural question

[Martin Makundi]

Why don't you just detach the entity/data objects with deep or shallow
clone or similar? Minimal duplication...

**
Martin

2012/2/12 Bas Gooren :
> Hi All,
>
> I have an architectural question about wicket, DDD and the service layer.
>
> Let's say we have a simple JPA entity (Customer), and a few simple CRUDL
> screens.
> For database access, we have a DAO layer (CustomerDao) which delegates to an
> EntityManager, and provides some convenience methods for searching.
> We also like to have clear boundaries, so we have a thin service layer which
> wraps persist() and delete() calls in a transaction before forwarding them
> to the DAO layer (@Transactional, as provided by guice-persist).
>
> A wicket model fetches one or more customers (by id or by running a search),
> and attaches to a form. In the form we use PropertyModels which push their
> changes to the entity, and in onSubmit() we call service.persist(entity).
> This means that the actual changes to the model happen outside of the
> transaction (in wicket code), and within the transaction (/service layer) we
> merely call persist() and flush().
>
> Then parts of the app need something a bit more advanced, so we decide to
> apply parts of DDD and put logic where it belongs (on the domain models).
> However, some logic coordinates multiple models, so we add a domain- or
> application-service for that.
> The good thing about DDD is that it's a lot more clear what happens
> (intent). We now realize that having a persist() method on a entity-based
> service now looks like a bit of a code smell, since it does not capture
> intent at all. Also, since the changes to the model happen in wicket, before
> the service layer is called, I feel that the service layer is not doing
> anything to act as a boundary. We might as well mark the persist() method on
> our daos @transactional and remove the service layer.
>
> The only clean way to fix this seems to be either:
> (a) using DTO's so the UI/wicket is not actually modifying domain entities
>    upside: the state of the domain is not modified by wicket itself
>    downside: duplication of models (actual model + DTO);
>    downside: validation is currently set-up in wicket by scanning fields for
> validation annotations, so we would need to duplicate those on the DTO?
>
> (b) using a concept from CQRS: sending commands to the domain through a bus.
> This clearly and cleanly defines the intent and captures the exact change.
>    upside: the state of the domain is not modified by wicket itself
>    downside: likely overkill for what we are trying to achieve; lot of extra
> complexity
>
> (c) wrapping the entire request in a transaction
>    upside: easy to implement
>    downside: since anything in the request can fetch a dao, read some
> entities and modify them, this means we can lose track of what happens in a
> request;
>    downside: feels like moving backwards
>
> (d) simplify by removing thin services and, where necessary, putting more
> logic in the dao's
>    upside: simple api contract: want to save/update an entity? use the dao
> directly
>    downside: dao's contain logic which does not really belong there
>    downside: if at some point we really do need a service, the api contract
> becomes less clear: for X and Y you can use the dao, for Z you have to use a
> service
>
> (a) and (b) provide a way to capture a change and execute all of the change
> inside a transaction.
>
> So my question to the list is: what are your experiences with this? How do
> you deal with this in simple to moderately complex webapps?
>
> Thanks for reading!

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Architectural question

[James Carman]

I just use open session in view.  You can still retrieve stuff outside a
transaction.  I explicitly call update to persist.
On Feb 12, 2012 7:54 AM, "Bas Gooren"  wrote:

> Hi All,
>
> I have an architectural question about wicket, DDD and the service layer.
>
> Let's say we have a simple JPA entity (Customer), and a few simple CRUDL
> screens.
> For database access, we have a DAO layer (CustomerDao) which delegates to
> an EntityManager, and provides some convenience methods for searching.
> We also like to have clear boundaries, so we have a thin service layer
> which wraps persist() and delete() calls in a transaction before forwarding
> them to the DAO layer (@Transactional, as provided by guice-persist).
>
> A wicket model fetches one or more customers (by id or by running a
> search), and attaches to a form. In the form we use PropertyModels which
> push their changes to the entity, and in onSubmit() we call
> service.persist(entity).
> This means that the actual changes to the model happen outside of the
> transaction (in wicket code), and within the transaction (/service layer)
> we merely call persist() and flush().
>
> Then parts of the app need something a bit more advanced, so we decide to
> apply parts of DDD and put logic where it belongs (on the domain models).
> However, some logic coordinates multiple models, so we add a domain- or
> application-service for that.
> The good thing about DDD is that it's a lot more clear what happens
> (intent). We now realize that having a persist() method on a entity-based
> service now looks like a bit of a code smell, since it does not capture
> intent at all. Also, since the changes to the model happen in wicket,
> before the service layer is called, I feel that the service layer is not
> doing anything to act as a boundary. We might as well mark the persist()
> method on our daos @transactional and remove the service layer.
>
> The only clean way to fix this seems to be either:
> (a) using DTO's so the UI/wicket is not actually modifying domain entities
>upside: the state of the domain is not modified by wicket itself
>downside: duplication of models (actual model + DTO);
>downside: validation is currently set-up in wicket by scanning fields
> for validation annotations, so we would need to duplicate those on the DTO?
>
> (b) using a concept from CQRS: sending commands to the domain through a
> bus. This clearly and cleanly defines the intent and captures the exact
> change.
>upside: the state of the domain is not modified by wicket itself
>downside: likely overkill for what we are trying to achieve; lot of
> extra complexity
>
> (c) wrapping the entire request in a transaction
>upside: easy to implement
>downside: since anything in the request can fetch a dao, read some
> entities and modify them, this means we can lose track of what happens in a
> request;
>downside: feels like moving backwards
>
> (d) simplify by removing thin services and, where necessary, putting more
> logic in the dao's
>upside: simple api contract: want to save/update an entity? use the dao
> directly
>downside: dao's contain logic which does not really belong there
>downside: if at some point we really do need a service, the api
> contract becomes less clear: for X and Y you can use the dao, for Z you
> have to use a service
>
> (a) and (b) provide a way to capture a change and execute all of the
> change inside a transaction.
>
> So my question to the list is: what are your experiences with this? How do
> you deal with this in simple to moderately complex webapps?
>
> Thanks for reading!
>

Re: Architectural question

[Bas Gooren]

Ok, so you mean detaching entities when returning them to the view layer 
(wicket)?


How do you propose updating the underlying entities? Send the detached 
entities back to the service layer and copying their changes to attached 
entities? Or ...?


Op 12-2-2012 14:22, schreef Martin Makundi:

Why don't you just detach the entity/data objects with deep or shallow
clone or similar? Minimal duplication...

**
Martin

2012/2/12 Bas Gooren:

Hi All,

I have an architectural question about wicket, DDD and the service layer.

Let's say we have a simple JPA entity (Customer), and a few simple CRUDL
screens.
For database access, we have a DAO layer (CustomerDao) which delegates to an
EntityManager, and provides some convenience methods for searching.
We also like to have clear boundaries, so we have a thin service layer which
wraps persist() and delete() calls in a transaction before forwarding them
to the DAO layer (@Transactional, as provided by guice-persist).

A wicket model fetches one or more customers (by id or by running a search),
and attaches to a form. In the form we use PropertyModels which push their
changes to the entity, and in onSubmit() we call service.persist(entity).
This means that the actual changes to the model happen outside of the
transaction (in wicket code), and within the transaction (/service layer) we
merely call persist() and flush().

Then parts of the app need something a bit more advanced, so we decide to
apply parts of DDD and put logic where it belongs (on the domain models).
However, some logic coordinates multiple models, so we add a domain- or
application-service for that.
The good thing about DDD is that it's a lot more clear what happens
(intent). We now realize that having a persist() method on a entity-based
service now looks like a bit of a code smell, since it does not capture
intent at all. Also, since the changes to the model happen in wicket, before
the service layer is called, I feel that the service layer is not doing
anything to act as a boundary. We might as well mark the persist() method on
our daos @transactional and remove the service layer.

The only clean way to fix this seems to be either:
(a) using DTO's so the UI/wicket is not actually modifying domain entities
upside: the state of the domain is not modified by wicket itself
downside: duplication of models (actual model + DTO);
downside: validation is currently set-up in wicket by scanning fields for
validation annotations, so we would need to duplicate those on the DTO?

(b) using a concept from CQRS: sending commands to the domain through a bus.
This clearly and cleanly defines the intent and captures the exact change.
upside: the state of the domain is not modified by wicket itself
downside: likely overkill for what we are trying to achieve; lot of extra
complexity

(c) wrapping the entire request in a transaction
upside: easy to implement
downside: since anything in the request can fetch a dao, read some
entities and modify them, this means we can lose track of what happens in a
request;
downside: feels like moving backwards

(d) simplify by removing thin services and, where necessary, putting more
logic in the dao's
upside: simple api contract: want to save/update an entity? use the dao
directly
downside: dao's contain logic which does not really belong there
downside: if at some point we really do need a service, the api contract
becomes less clear: for X and Y you can use the dao, for Z you have to use a
service

(a) and (b) provide a way to capture a change and execute all of the change
inside a transaction.

So my question to the list is: what are your experiences with this? How do
you deal with this in simple to moderately complex webapps?

Thanks for reading!

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Architectural question

[Martin Makundi]

Yeah.. what we do is we detach entities when loading from service
layer to view layer and when user is ready to commit we persist them
on service layer overriding service layer state (standard locking
techniques here).

**
Martin

2012/2/12 Bas Gooren :
> Ok, so you mean detaching entities when returning them to the view layer
> (wicket)?
>
> How do you propose updating the underlying entities? Send the detached
> entities back to the service layer and copying their changes to attached
> entities? Or ...?
>
> Op 12-2-2012 14:22, schreef Martin Makundi:
>>
>> Why don't you just detach the entity/data objects with deep or shallow
>> clone or similar? Minimal duplication...
>>
>> **
>> Martin
>>
>> 2012/2/12 Bas Gooren:
>>>
>>> Hi All,
>>>
>>> I have an architectural question about wicket, DDD and the service layer.
>>>
>>> Let's say we have a simple JPA entity (Customer), and a few simple CRUDL
>>> screens.
>>> For database access, we have a DAO layer (CustomerDao) which delegates to
>>> an
>>> EntityManager, and provides some convenience methods for searching.
>>> We also like to have clear boundaries, so we have a thin service layer
>>> which
>>> wraps persist() and delete() calls in a transaction before forwarding
>>> them
>>> to the DAO layer (@Transactional, as provided by guice-persist).
>>>
>>> A wicket model fetches one or more customers (by id or by running a
>>> search),
>>> and attaches to a form. In the form we use PropertyModels which push
>>> their
>>> changes to the entity, and in onSubmit() we call service.persist(entity).
>>> This means that the actual changes to the model happen outside of the
>>> transaction (in wicket code), and within the transaction (/service layer)
>>> we
>>> merely call persist() and flush().
>>>
>>> Then parts of the app need something a bit more advanced, so we decide to
>>> apply parts of DDD and put logic where it belongs (on the domain models).
>>> However, some logic coordinates multiple models, so we add a domain- or
>>> application-service for that.
>>> The good thing about DDD is that it's a lot more clear what happens
>>> (intent). We now realize that having a persist() method on a entity-based
>>> service now looks like a bit of a code smell, since it does not capture
>>> intent at all. Also, since the changes to the model happen in wicket,
>>> before
>>> the service layer is called, I feel that the service layer is not doing
>>> anything to act as a boundary. We might as well mark the persist() method
>>> on
>>> our daos @transactional and remove the service layer.
>>>
>>> The only clean way to fix this seems to be either:
>>> (a) using DTO's so the UI/wicket is not actually modifying domain
>>> entities
>>>    upside: the state of the domain is not modified by wicket itself
>>>    downside: duplication of models (actual model + DTO);
>>>    downside: validation is currently set-up in wicket by scanning fields
>>> for
>>> validation annotations, so we would need to duplicate those on the DTO?
>>>
>>> (b) using a concept from CQRS: sending commands to the domain through a
>>> bus.
>>> This clearly and cleanly defines the intent and captures the exact
>>> change.
>>>    upside: the state of the domain is not modified by wicket itself
>>>    downside: likely overkill for what we are trying to achieve; lot of
>>> extra
>>> complexity
>>>
>>> (c) wrapping the entire request in a transaction
>>>    upside: easy to implement
>>>    downside: since anything in the request can fetch a dao, read some
>>> entities and modify them, this means we can lose track of what happens in
>>> a
>>> request;
>>>    downside: feels like moving backwards
>>>
>>> (d) simplify by removing thin services and, where necessary, putting more
>>> logic in the dao's
>>>    upside: simple api contract: want to save/update an entity? use the
>>> dao
>>> directly
>>>    downside: dao's contain logic which does not really belong there
>>>    downside: if at some point we really do need a service, the api
>>> contract
>>> becomes less clear: for X and Y you can use the dao, for Z you have to
>>> use a
>>> service
>>>
>>> (a) and (b) provide a way to capture a change and execute all of the
>>> change
>>> inside a transaction.
>>>
>>> So my question to the list is: what are your experiences with this? How
>>> do
>>> you deal with this in simple to moderately complex webapps?
>>>
>>> Thanks for reading!
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Architectural question

[Bas Gooren]

Martin,

Ok, and do you perform all such copying manually or do you use something 
automated for that? (Or simply a JPA merge?)


Op 12-2-2012 16:22, schreef Martin Makundi:

Yeah.. what we do is we detach entities when loading from service
layer to view layer and when user is ready to commit we persist them
on service layer overriding service layer state (standard locking
techniques here).

**
Martin

2012/2/12 Bas Gooren:

Ok, so you mean detaching entities when returning them to the view layer
(wicket)?

How do you propose updating the underlying entities? Send the detached
entities back to the service layer and copying their changes to attached
entities? Or ...?

Op 12-2-2012 14:22, schreef Martin Makundi:

Why don't you just detach the entity/data objects with deep or shallow
clone or similar? Minimal duplication...

**
Martin

2012/2/12 Bas Gooren:

Hi All,

I have an architectural question about wicket, DDD and the service layer.

Let's say we have a simple JPA entity (Customer), and a few simple CRUDL
screens.
For database access, we have a DAO layer (CustomerDao) which delegates to
an
EntityManager, and provides some convenience methods for searching.
We also like to have clear boundaries, so we have a thin service layer
which
wraps persist() and delete() calls in a transaction before forwarding
them
to the DAO layer (@Transactional, as provided by guice-persist).

A wicket model fetches one or more customers (by id or by running a
search),
and attaches to a form. In the form we use PropertyModels which push
their
changes to the entity, and in onSubmit() we call service.persist(entity).
This means that the actual changes to the model happen outside of the
transaction (in wicket code), and within the transaction (/service layer)
we
merely call persist() and flush().

Then parts of the app need something a bit more advanced, so we decide to
apply parts of DDD and put logic where it belongs (on the domain models).
However, some logic coordinates multiple models, so we add a domain- or
application-service for that.
The good thing about DDD is that it's a lot more clear what happens
(intent). We now realize that having a persist() method on a entity-based
service now looks like a bit of a code smell, since it does not capture
intent at all. Also, since the changes to the model happen in wicket,
before
the service layer is called, I feel that the service layer is not doing
anything to act as a boundary. We might as well mark the persist() method
on
our daos @transactional and remove the service layer.

The only clean way to fix this seems to be either:
(a) using DTO's so the UI/wicket is not actually modifying domain
entities
upside: the state of the domain is not modified by wicket itself
downside: duplication of models (actual model + DTO);
downside: validation is currently set-up in wicket by scanning fields
for
validation annotations, so we would need to duplicate those on the DTO?

(b) using a concept from CQRS: sending commands to the domain through a
bus.
This clearly and cleanly defines the intent and captures the exact
change.
upside: the state of the domain is not modified by wicket itself
downside: likely overkill for what we are trying to achieve; lot of
extra
complexity

(c) wrapping the entire request in a transaction
upside: easy to implement
downside: since anything in the request can fetch a dao, read some
entities and modify them, this means we can lose track of what happens in
a
request;
downside: feels like moving backwards

(d) simplify by removing thin services and, where necessary, putting more
logic in the dao's
upside: simple api contract: want to save/update an entity? use the
dao
directly
downside: dao's contain logic which does not really belong there
downside: if at some point we really do need a service, the api
contract
becomes less clear: for X and Y you can use the dao, for Z you have to
use a
service

(a) and (b) provide a way to capture a change and execute all of the
change
inside a transaction.

So my question to the list is: what are your experiences with this? How
do
you deal with this in simple to moderately complex webapps?

Thanks for reading!

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Architectural question

[Bas Gooren]

We already use OSIV, thanks to guice-persist.
This means the read-side of things is rather trivial, and that the 
service and dao layers do need to be aware of the exact data the view 
needs (since lazy loading is possible).


With regard to the write-side of things: we do what you do (call update 
explicitly) right now.


Suppose you are using DDD in a project, how would you go about 
constructing and populating a new object? Without DDD my entities were 
mere containers for data with some validation and JPA annotations. So it 
was simply a matter of creating a Model which wraps a "new Customer", 
and wicket pushing its fields to that customer object.


However, when applying DDD, that Customer is no longer a simple 
container, but a business object. Having wicket push changes directly to 
fields (those fields may even be private-access only, without setters) 
seems to go against DDD fashion.


So I feel it would be better to create a DTO for a certain view (e.g. 
NewCustomerDTO for a CreateCustomerPanel), and putting all validation 
annotations on the DTO, too. When it's time to persist the new customer, 
the service layer simply creates a new customer and copies all fields 
from the DTO.


But then again, maybe this is overcomplicating things. DDD seems like a 
good match for most of my projects though, and I'd like to be able to 
properly integrate my domain objects with wicket.


Op 12-2-2012 15:17, schreef James Carman:

I just use open session in view.  You can still retrieve stuff outside a
transaction.  I explicitly call update to persist.
On Feb 12, 2012 7:54 AM, "Bas Gooren"  wrote:


Hi All,

I have an architectural question about wicket, DDD and the service layer.

Let's say we have a simple JPA entity (Customer), and a few simple CRUDL
screens.
For database access, we have a DAO layer (CustomerDao) which delegates to
an EntityManager, and provides some convenience methods for searching.
We also like to have clear boundaries, so we have a thin service layer
which wraps persist() and delete() calls in a transaction before forwarding
them to the DAO layer (@Transactional, as provided by guice-persist).

A wicket model fetches one or more customers (by id or by running a
search), and attaches to a form. In the form we use PropertyModels which
push their changes to the entity, and in onSubmit() we call
service.persist(entity).
This means that the actual changes to the model happen outside of the
transaction (in wicket code), and within the transaction (/service layer)
we merely call persist() and flush().

Then parts of the app need something a bit more advanced, so we decide to
apply parts of DDD and put logic where it belongs (on the domain models).
However, some logic coordinates multiple models, so we add a domain- or
application-service for that.
The good thing about DDD is that it's a lot more clear what happens
(intent). We now realize that having a persist() method on a entity-based
service now looks like a bit of a code smell, since it does not capture
intent at all. Also, since the changes to the model happen in wicket,
before the service layer is called, I feel that the service layer is not
doing anything to act as a boundary. We might as well mark the persist()
method on our daos @transactional and remove the service layer.

The only clean way to fix this seems to be either:
(a) using DTO's so the UI/wicket is not actually modifying domain entities
upside: the state of the domain is not modified by wicket itself
downside: duplication of models (actual model + DTO);
downside: validation is currently set-up in wicket by scanning fields
for validation annotations, so we would need to duplicate those on the DTO?

(b) using a concept from CQRS: sending commands to the domain through a
bus. This clearly and cleanly defines the intent and captures the exact
change.
upside: the state of the domain is not modified by wicket itself
downside: likely overkill for what we are trying to achieve; lot of
extra complexity

(c) wrapping the entire request in a transaction
upside: easy to implement
downside: since anything in the request can fetch a dao, read some
entities and modify them, this means we can lose track of what happens in a
request;
downside: feels like moving backwards

(d) simplify by removing thin services and, where necessary, putting more
logic in the dao's
upside: simple api contract: want to save/update an entity? use the dao
directly
downside: dao's contain logic which does not really belong there
downside: if at some point we really do need a service, the api
contract becomes less clear: for X and Y you can use the dao, for Z you
have to use a service

(a) and (b) provide a way to capture a change and execute all of the
change inside a transaction.

So my question to the list is: what are your experiences with this? How do
you deal with this in simple to moderately complex webapps?

Thanks for reading!

Re: Architectural question

[Martin Makundi]

> Ok, and do you perform all such copying manually or do you use something
> automated for that? (Or simply a JPA merge?)

Yes, merge for simplicity, and if we have a custom caching mechanism
we simply replace the node object in a hashmap.

**
Martin

>
> Op 12-2-2012 16:22, schreef Martin Makundi:
>>
>> Yeah.. what we do is we detach entities when loading from service
>> layer to view layer and when user is ready to commit we persist them
>> on service layer overriding service layer state (standard locking
>> techniques here).
>>
>> **
>> Martin
>>
>> 2012/2/12 Bas Gooren:
>>>
>>> Ok, so you mean detaching entities when returning them to the view layer
>>> (wicket)?
>>>
>>> How do you propose updating the underlying entities? Send the detached
>>> entities back to the service layer and copying their changes to attached
>>> entities? Or ...?
>>>
>>> Op 12-2-2012 14:22, schreef Martin Makundi:

 Why don't you just detach the entity/data objects with deep or shallow
 clone or similar? Minimal duplication...

 **
 Martin

 2012/2/12 Bas Gooren:
>
> Hi All,
>
> I have an architectural question about wicket, DDD and the service
> layer.
>
> Let's say we have a simple JPA entity (Customer), and a few simple
> CRUDL
> screens.
> For database access, we have a DAO layer (CustomerDao) which delegates
> to
> an
> EntityManager, and provides some convenience methods for searching.
> We also like to have clear boundaries, so we have a thin service layer
> which
> wraps persist() and delete() calls in a transaction before forwarding
> them
> to the DAO layer (@Transactional, as provided by guice-persist).
>
> A wicket model fetches one or more customers (by id or by running a
> search),
> and attaches to a form. In the form we use PropertyModels which push
> their
> changes to the entity, and in onSubmit() we call
> service.persist(entity).
> This means that the actual changes to the model happen outside of the
> transaction (in wicket code), and within the transaction (/service
> layer)
> we
> merely call persist() and flush().
>
> Then parts of the app need something a bit more advanced, so we decide
> to
> apply parts of DDD and put logic where it belongs (on the domain
> models).
> However, some logic coordinates multiple models, so we add a domain- or
> application-service for that.
> The good thing about DDD is that it's a lot more clear what happens
> (intent). We now realize that having a persist() method on a
> entity-based
> service now looks like a bit of a code smell, since it does not capture
> intent at all. Also, since the changes to the model happen in wicket,
> before
> the service layer is called, I feel that the service layer is not doing
> anything to act as a boundary. We might as well mark the persist()
> method
> on
> our daos @transactional and remove the service layer.
>
> The only clean way to fix this seems to be either:
> (a) using DTO's so the UI/wicket is not actually modifying domain
> entities
>    upside: the state of the domain is not modified by wicket itself
>    downside: duplication of models (actual model + DTO);
>    downside: validation is currently set-up in wicket by scanning
> fields
> for
> validation annotations, so we would need to duplicate those on the DTO?
>
> (b) using a concept from CQRS: sending commands to the domain through a
> bus.
> This clearly and cleanly defines the intent and captures the exact
> change.
>    upside: the state of the domain is not modified by wicket itself
>    downside: likely overkill for what we are trying to achieve; lot of
> extra
> complexity
>
> (c) wrapping the entire request in a transaction
>    upside: easy to implement
>    downside: since anything in the request can fetch a dao, read some
> entities and modify them, this means we can lose track of what happens
> in
> a
> request;
>    downside: feels like moving backwards
>
> (d) simplify by removing thin services and, where necessary, putting
> more
> logic in the dao's
>    upside: simple api contract: want to save/update an entity? use the
> dao
> directly
>    downside: dao's contain logic which does not really belong there
>    downside: if at some point we really do need a service, the api
> contract
> becomes less clear: for X and Y you can use the dao, for Z you have to
> use a
> service
>
> (a) and (b) provide a way to capture a change and execute all of the
> change
> inside a transaction.
>
> So my question to the list is: what are your experiences with this? How
> do
> you deal with this in simple to moderately complex webapps?
>
> Thanks for readi

Re: AjaxTabbedPanel - Enable / Disable Individual Tab.

[ej595]

Thank You.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/AjaxTabbedPanel-Enable-Disable-Individual-Tab-tp4380339p4381444.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Architectural question

[James Carman]

Well setters/getters somewhat go against ddd.  We just have to figure out
what works for us.  It's all about finding what gets the job done most
effectively.
On Feb 12, 2012 10:45 AM, "Bas Gooren"  wrote:

> We already use OSIV, thanks to guice-persist.
> This means the read-side of things is rather trivial, and that the service
> and dao layers do need to be aware of the exact data the view needs (since
> lazy loading is possible).
>
> With regard to the write-side of things: we do what you do (call update
> explicitly) right now.
>
> Suppose you are using DDD in a project, how would you go about
> constructing and populating a new object? Without DDD my entities were mere
> containers for data with some validation and JPA annotations. So it was
> simply a matter of creating a Model which wraps a "new Customer", and
> wicket pushing its fields to that customer object.
>
> However, when applying DDD, that Customer is no longer a simple container,
> but a business object. Having wicket push changes directly to fields (those
> fields may even be private-access only, without setters) seems to go
> against DDD fashion.
>
> So I feel it would be better to create a DTO for a certain view (e.g.
> NewCustomerDTO for a CreateCustomerPanel), and putting all validation
> annotations on the DTO, too. When it's time to persist the new customer,
> the service layer simply creates a new customer and copies all fields from
> the DTO.
>
> But then again, maybe this is overcomplicating things. DDD seems like a
> good match for most of my projects though, and I'd like to be able to
> properly integrate my domain objects with wicket.
>
> Op 12-2-2012 15:17, schreef James Carman:
>
>> I just use open session in view.  You can still retrieve stuff outside a
>> transaction.  I explicitly call update to persist.
>> On Feb 12, 2012 7:54 AM, "Bas Gooren"  wrote:
>>
>>  Hi All,
>>>
>>> I have an architectural question about wicket, DDD and the service layer.
>>>
>>> Let's say we have a simple JPA entity (Customer), and a few simple CRUDL
>>> screens.
>>> For database access, we have a DAO layer (CustomerDao) which delegates to
>>> an EntityManager, and provides some convenience methods for searching.
>>> We also like to have clear boundaries, so we have a thin service layer
>>> which wraps persist() and delete() calls in a transaction before
>>> forwarding
>>> them to the DAO layer (@Transactional, as provided by guice-persist).
>>>
>>> A wicket model fetches one or more customers (by id or by running a
>>> search), and attaches to a form. In the form we use PropertyModels which
>>> push their changes to the entity, and in onSubmit() we call
>>> service.persist(entity).
>>> This means that the actual changes to the model happen outside of the
>>> transaction (in wicket code), and within the transaction (/service layer)
>>> we merely call persist() and flush().
>>>
>>> Then parts of the app need something a bit more advanced, so we decide to
>>> apply parts of DDD and put logic where it belongs (on the domain models).
>>> However, some logic coordinates multiple models, so we add a domain- or
>>> application-service for that.
>>> The good thing about DDD is that it's a lot more clear what happens
>>> (intent). We now realize that having a persist() method on a entity-based
>>> service now looks like a bit of a code smell, since it does not capture
>>> intent at all. Also, since the changes to the model happen in wicket,
>>> before the service layer is called, I feel that the service layer is not
>>> doing anything to act as a boundary. We might as well mark the persist()
>>> method on our daos @transactional and remove the service layer.
>>>
>>> The only clean way to fix this seems to be either:
>>> (a) using DTO's so the UI/wicket is not actually modifying domain
>>> entities
>>>upside: the state of the domain is not modified by wicket itself
>>>downside: duplication of models (actual model + DTO);
>>>downside: validation is currently set-up in wicket by scanning fields
>>> for validation annotations, so we would need to duplicate those on the
>>> DTO?
>>>
>>> (b) using a concept from CQRS: sending commands to the domain through a
>>> bus. This clearly and cleanly defines the intent and captures the exact
>>> change.
>>>upside: the state of the domain is not modified by wicket itself
>>>downside: likely overkill for what we are trying to achieve; lot of
>>> extra complexity
>>>
>>> (c) wrapping the entire request in a transaction
>>>upside: easy to implement
>>>downside: since anything in the request can fetch a dao, read some
>>> entities and modify them, this means we can lose track of what happens
>>> in a
>>> request;
>>>downside: feels like moving backwards
>>>
>>> (d) simplify by removing thin services and, where necessary, putting more
>>> logic in the dao's
>>>upside: simple api contract: want to save/update an entity? use the
>>> dao
>>> directly
>>>downside: dao's contain logic which

component.isAuto - was: Wicket 1.5: The component(s) below failed to render (revisited)

[Adrian Wiesmann]

Hello list

Some while ago I posted a few messages to this list where I asked for 
help in finding a problem with Wicket 1.5. I was not able to find the 
bug back then. Now I downloaded the bleeding edge version 1.5.4 and 
tried again. And now I am a step further.


I have that rendering engine where I take an XML file, build an object 
tree from that and have a renderer rendering a Wicket object tree and 
finally Wicket which renders the HTML UI from that.


Now I noticed with version 1.5 of Wicket, that this line in the 
org.apache.wicket.Page.class are the key to my problem (lines 611, 612):


// If not an auto component ...
if (!component.isAuto() && component.isVisibleInHierarchy())

I noticed that many of my components I add in my renderer on the fly are 
returning isAuto = false on that line (and of course they are visible, 
which adds them to unrenderedComponents and ultimately provokes the error).


I then added this.setAuto(true); in one of my components. And voila, it 
was not in the list of components which failed to render.


So here are my questions:

- What did change from version 1.4.x to version 1.5.x that results in 
this error?

- Is that a bug in Wicket or do I need to fix my renderer somehow?
- What side effects does it have if I just add a setAuto(true) to all of 
my components?


Thanks for your help!

Cheers,
Adrian

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Link URLs with JSessionID truncated

[Ian Marshall]

Hello All,

A user's first visit to my app's home page results in the URL

  http://[My domain]/main/PageHome;jsessionid=v_qqIGVQlKBbkNSOcHkAQw?0

Each org.apache.wicket.markup.html.link.Link on my home page has the URL of
the form

  http://[My
domain]/main/..;jsessionid=v_qqIGVQlKBbkNSOcHkAQw?0-1.ILinkListener-lnkAbout

(of length 102 characters for the particular link URL copied here). These
URLs are invalid, because of the two dots present instead of the completed
path.

Is there any way I can configure Wicket to suppress this URL abbreviation,
or is this operation the province of the web application server or web
browser?

As a work-around, I have already coded the supression of JSessionIDs in my
links' URLs, and am coding the app to give a warning if session cookies are
disabled. But I would appreciate any pointers.

Ian Marshall


My operating environment
-
Web application server: (Jetty? in) Google App Engine
Wicket version: 1.5.3 (I know: it's not the very latest version!)
Web browsers:   Mozilla Firefox 10.0.1
Microsoft Internet Explorer 8.0.6001.18702
as found on my HTC Wildfire S running Google Android
2.3.5

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Link-URLs-with-JSessionID-truncated-tp4381881p4381881.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Architectural question

[Chris Colman]

It sounds like you have a lot of layers/scaffolding (=high maintenance)
in your design.

The "exposed domain model" pattern was created to avoid all those extra
layers (especially DAOs and DTOs) in recognition of the fact that for
most applications they *feel* redundant and *seem* like code
duplication.

I understand the puritan goals that bring about the adoption of DTOs but
IMHO introducing them forms a slippery slope to "productivity
impedance".

We adopted the Exposed Domain Model (EDM) pattern with "Open
[Session|PersistenceManager] In View" many years ago and haven't created
a DAO or DTO since - and development has been easier, faster and more
maintainable since.

EDM still does provide for Respositories (object search, looks ups,
etc., - where your queries reside) and Services (where you orchestrate
non trivial model changes, updates) but for the most part if the UI is
simply CRUDing a model object we expose that model object and let it
call the setters and getters directly.

We even allow some trivial persistent objects to be instantiated
directly by the UI where that is appropriate. With 'persistence by
reachability' (we use JDO - JPA might also have this) it's not even
necessary to call persist() on the newly constructed instances if they
are reachable by at least one already persisted object.

In certain cases where instantiation of an object graph must be
orchestrated according to some business rules or some constraints
implicit in the model we do either of the following:

1. make the domain class' constructors private and force instantiation
to take place via a static method on the particular class.

2. make the domain class' constructors protected and force instantiation
to take place via a Service provided for the package in which the new
class exists.

It's been working flawlessly for us and our domain model now has over
300 persistent classes. I doubt we would have been able to grow it this
fast if we had the extra development burden of developing and creating
DAO and DTO classes on the way. Also the code base would probably be
close to double what it is today.

Having let our hair down this much we must state that we still are 100%
puritan when it comes to separation of Model and Presentation layer. The
model itself has ZERO dependencies on any UI code and can be compiled
completely independently of the UI.

>-Original Message-
>From: James Carman [mailto:jcar...@carmanconsulting.com]
>Sent: Monday, 13 February 2012 4:40 AM
>To: users@wicket.apache.org
>Subject: Re: Architectural question
>
>Well setters/getters somewhat go against ddd.  We just have to figure
out
>what works for us.  It's all about finding what gets the job done most
>effectively.
>On Feb 12, 2012 10:45 AM, "Bas Gooren"  wrote:
>
>> We already use OSIV, thanks to guice-persist.
>> This means the read-side of things is rather trivial, and that the
>service
>> and dao layers do need to be aware of the exact data the view needs
>(since
>> lazy loading is possible).
>>
>> With regard to the write-side of things: we do what you do (call
update
>> explicitly) right now.
>>
>> Suppose you are using DDD in a project, how would you go about
>> constructing and populating a new object? Without DDD my entities
were
>mere
>> containers for data with some validation and JPA annotations. So it
was
>> simply a matter of creating a Model which wraps a "new Customer", and
>> wicket pushing its fields to that customer object.
>>
>> However, when applying DDD, that Customer is no longer a simple
>container,
>> but a business object. Having wicket push changes directly to fields
>(those
>> fields may even be private-access only, without setters) seems to go
>> against DDD fashion.
>>
>> So I feel it would be better to create a DTO for a certain view (e.g.
>> NewCustomerDTO for a CreateCustomerPanel), and putting all validation
>> annotations on the DTO, too. When it's time to persist the new
customer,
>> the service layer simply creates a new customer and copies all fields
>from
>> the DTO.
>>
>> But then again, maybe this is overcomplicating things. DDD seems like
a
>> good match for most of my projects though, and I'd like to be able to
>> properly integrate my domain objects with wicket.
>>
>> Op 12-2-2012 15:17, schreef James Carman:
>>
>>> I just use open session in view.  You can still retrieve stuff
outside a
>>> transaction.  I explicitly call update to persist.
>>> On Feb 12, 2012 7:54 AM, "Bas Gooren"  wrote:
>>>
>>>  Hi All,

 I have an architectural question about wicket, DDD and the service
>layer.

 Let's say we have a simple JPA entity (Customer), and a few simple
>CRUDL
 screens.
 For database access, we have a DAO layer (CustomerDao) which
delegates
>to
 an EntityManager, and provides some convenience methods for
searching.
 We also like to have clear boundaries, so we have a thin service
layer
 which wraps persist() and delete() calls in a transaction before
 forwarding
 

RE: Link URLs with JSessionID truncated

[Chris Colman]

If a user has disabled session cookies your Wicket app will still work
fine using URL rewriting.

If you stop the URL rewriting and give a message to people who have
disabled cookies you will prevent a certain % of visitors from using
your web app.

I'm not sure what that % of people is but in the past some people have
believed the mantra that 'enabling cookies' is security hole/privacy
issue. I've never believed that mantra but there is quite possibly a %
of the population that do and so disabled cookies.


>-Original Message-
>From: Ian Marshall [mailto:ianmarshall...@gmail.com]
>Sent: Monday, 13 February 2012 7:13 AM
>To: users@wicket.apache.org
>Subject: Link URLs with JSessionID truncated
>
>Hello All,
>
>A user's first visit to my app's home page results in the URL
>
>  http://[My domain]/main/PageHome;jsessionid=v_qqIGVQlKBbkNSOcHkAQw?0
>
>Each org.apache.wicket.markup.html.link.Link on my home page has the
URL of
>the form
>
>  http://[My
>domain]/main/..;jsessionid=v_qqIGVQlKBbkNSOcHkAQw?0-1.ILinkListener-
>lnkAbout
>
>(of length 102 characters for the particular link URL copied here).
These
>URLs are invalid, because of the two dots present instead of the
completed
>path.
>
>Is there any way I can configure Wicket to suppress this URL
abbreviation,
>or is this operation the province of the web application server or web
>browser?
>
>As a work-around, I have already coded the supression of JSessionIDs in
my
>links' URLs, and am coding the app to give a warning if session cookies
are
>disabled. But I would appreciate any pointers.
>
>Ian Marshall
>
>
>My operating environment
>-
>Web application server: (Jetty? in) Google App Engine
>Wicket version: 1.5.3 (I know: it's not the very latest
version!)
>Web browsers:   Mozilla Firefox 10.0.1
>Microsoft Internet Explorer 8.0.6001.18702
>as found on my HTC Wildfire S running Google
>Android
>2.3.5
>
>--
>View this message in context: http://apache-
>wicket.1842946.n4.nabble.com/Link-URLs-with-JSessionID-truncated-
>tp4381881p4381881.html
>Sent from the Users forum mailing list archive at Nabble.com.
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

StringResources in forms based on 'variation'

[Chris Colman]

I configure StringResources for forms using the FormClass.properties
file and this works well.
 
Different strings can be provided for lang, locale etc.,
 
Is it possible to provide a different string based on the markup
'variation'
 
Yours sincerely,
 
Chris Colman
 
Pagebloom Team Leader,
Step Ahead Software

 
pagebloom - your business & your website growing together
 
Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 
Email: chr...@stepahead.com.au  
Website:
http://www.pagebloom.com http://www.pagebloom.com/> 
http://develop.stepaheadsoftware.com
http://develop.stepaheadsoftware.com/> 
 
 

Re: Architectural question

[Igor Vaynberg]

we use a pretty thin architecture described here:

https://www.42lines.net/2011/11/29/leveraging-conversations/
https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/

this allows us to expose our domain model to the UI but control when
and where the updates actually happen.

together with https://github.com/42Lines/wicket-bean-validation you
can put your validation into your setters and get closer to the "true"
ddd way of doing things. also, setters can have sideeffects on the
subgraph of the entity and the UI will reflect them as well - all
without having to persist anything into the database in a "half-done"
state and without having to capture the complete state in a dto.

-igor

On Sun, Feb 12, 2012 at 4:53 AM, Bas Gooren  wrote:
> Hi All,
>
> I have an architectural question about wicket, DDD and the service layer.
>
> Let's say we have a simple JPA entity (Customer), and a few simple CRUDL
> screens.
> For database access, we have a DAO layer (CustomerDao) which delegates to an
> EntityManager, and provides some convenience methods for searching.
> We also like to have clear boundaries, so we have a thin service layer which
> wraps persist() and delete() calls in a transaction before forwarding them
> to the DAO layer (@Transactional, as provided by guice-persist).
>
> A wicket model fetches one or more customers (by id or by running a search),
> and attaches to a form. In the form we use PropertyModels which push their
> changes to the entity, and in onSubmit() we call service.persist(entity).
> This means that the actual changes to the model happen outside of the
> transaction (in wicket code), and within the transaction (/service layer) we
> merely call persist() and flush().
>
> Then parts of the app need something a bit more advanced, so we decide to
> apply parts of DDD and put logic where it belongs (on the domain models).
> However, some logic coordinates multiple models, so we add a domain- or
> application-service for that.
> The good thing about DDD is that it's a lot more clear what happens
> (intent). We now realize that having a persist() method on a entity-based
> service now looks like a bit of a code smell, since it does not capture
> intent at all. Also, since the changes to the model happen in wicket, before
> the service layer is called, I feel that the service layer is not doing
> anything to act as a boundary. We might as well mark the persist() method on
> our daos @transactional and remove the service layer.
>
> The only clean way to fix this seems to be either:
> (a) using DTO's so the UI/wicket is not actually modifying domain entities
>    upside: the state of the domain is not modified by wicket itself
>    downside: duplication of models (actual model + DTO);
>    downside: validation is currently set-up in wicket by scanning fields for
> validation annotations, so we would need to duplicate those on the DTO?
>
> (b) using a concept from CQRS: sending commands to the domain through a bus.
> This clearly and cleanly defines the intent and captures the exact change.
>    upside: the state of the domain is not modified by wicket itself
>    downside: likely overkill for what we are trying to achieve; lot of extra
> complexity
>
> (c) wrapping the entire request in a transaction
>    upside: easy to implement
>    downside: since anything in the request can fetch a dao, read some
> entities and modify them, this means we can lose track of what happens in a
> request;
>    downside: feels like moving backwards
>
> (d) simplify by removing thin services and, where necessary, putting more
> logic in the dao's
>    upside: simple api contract: want to save/update an entity? use the dao
> directly
>    downside: dao's contain logic which does not really belong there
>    downside: if at some point we really do need a service, the api contract
> becomes less clear: for X and Y you can use the dao, for Z you have to use a
> service
>
> (a) and (b) provide a way to capture a change and execute all of the change
> inside a transaction.
>
> So my question to the list is: what are your experiences with this? How do
> you deal with this in simple to moderately complex webapps?
>
> Thanks for reading!

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Link URLs with JSessionID truncated

[Ian Marshall]

Hi Chris,

I suppressed JSessionIDs in my links' URLs, not because I dislike them, but
solely because I found that my links' URLs were not working because the ".."
strings were appearing.

So, unless I can find a better way, I need to suppress the JSessionIDs and
require session cookie enablement. It's pants, but better than "Not found"
errors being presented to users following my links.

Cheers,

Ian

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Link-URLs-with-JSessionID-truncated-tp4381881p4382081.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Link URLs with JSessionID truncated

[Chris Colman]

"Not found" errors are bad.

What version of Wicket are you using?

>-Original Message-
>From: Ian Marshall [mailto:ianmarshall...@gmail.com]
>Sent: Monday, 13 February 2012 8:41 AM
>To: users@wicket.apache.org
>Subject: RE: Link URLs with JSessionID truncated
>
>Hi Chris,
>
>I suppressed JSessionIDs in my links' URLs, not because I dislike them,
but
>solely because I found that my links' URLs were not working because the
>".."
>strings were appearing.
>
>So, unless I can find a better way, I need to suppress the JSessionIDs
and
>require session cookie enablement. It's pants, but better than "Not
found"
>errors being presented to users following my links.
>
>Cheers,
>
>Ian
>
>--
>View this message in context: http://apache-
>wicket.1842946.n4.nabble.com/Link-URLs-with-JSessionID-truncated-
>tp4381881p4382081.html
>Sent from the Users forum mailing list archive at Nabble.com.
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: StringResources in forms based on 'variation'

[Chris Colman]

What I am trying to do is tailor the validator messages based on the
variation. 
 
My scenario:
 
Some clients want log in forms with "Username/Password" others want some
with "Email/Password" and still others want some with "Member
Number/Security Code".
 
I handle all the different types of log in forms with a single wicket
LoginPanel.java file but different variations - functionally they are
all the same but the wording on the screen is different. 
 
The wording that the validators use should reflect the fields in each of
the different variations.
 
For example on a Username/Password variation the username's Required
validator message should be:
 
"Please enter your username."
 
And not
 
"Please enter your email address."
 
If the properties files could support string definitions based on
variation as well as locale then this would be quite easy to do.
 
At the moment I can work around this using string definitions like:
 
Please enter your ${label}
 
and call setLabel on each form component passing in variation dependent
names but the ideal solution would be to specify these labels in a
variation specific way in the properties file.
 
 


From: Chris Colman [mailto:chr...@stepaheadsoftware.com] 
Sent: Monday, 13 February 2012 8:09 AM
To: users@wicket.apache.org
Subject: StringResources in forms based on 'variation'
 
I configure StringResources for forms using the FormClass.properties
file and this works well.
 
Different strings can be provided for lang, locale etc.,
 
Is it possible to provide a different string based on the markup
'variation'
 
Yours sincerely,
 
Chris Colman
 
Pagebloom Team Leader,
Step Ahead Software


pagebloom - your business & your website growing together
 
Sydney:   (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 
Email: chr...@stepahead.com.au  
Website:
http://www.pagebloom.com http://www.pagebloom.com/> 
http://develop.stepaheadsoftware.com
http://develop.stepaheadsoftware.com/> 
 
 

RE: Wicket 'hook' point for page render timing

[Chris Colman]

I've added the RenderPerformanceListener but where is the output? Where
can we retrieve the performance stats?

>-Original Message-
>From: robert.mcguinness [mailto:robert.mcguinness@gmail.com]
>Sent: Sunday, 12 February 2012 2:22 AM
>To: users@wicket.apache.org
>Subject: Re: Wicket 'hook' point for page render timing
>
>Chris,
>
>
>Have you looked into
>
>RenderPerformanceListener.java?
>
>added by
>
>getComponentInstantiationListeners().add(new
RenderPerformanceListener());
>
>--
>View this message in context: http://apache-
>wicket.1842946.n4.nabble.com/Wicket-hook-point-for-page-render-timing-
>tp4378230p4379127.html
>Sent from the Users forum mailing list archive at Nabble.com.
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: StringResources in forms based on 'variation'

[Andrea Del Bene]

Hi,

you can consider to use Style element used by Wicket for skinning 
application. For more information read this


https://cwiki.apache.org/WICKET/localization-and-skinning-of-applications.html

What I am trying to do is tailor the validator messages based on the
variation.

My scenario:

Some clients want log in forms with "Username/Password" others want some
with "Email/Password" and still others want some with "Member
Number/Security Code".

I handle all the different types of log in forms with a single wicket
LoginPanel.java file but different variations - functionally they are
all the same but the wording on the screen is different.

The wording that the validators use should reflect the fields in each of
the different variations.

For example on a Username/Password variation the username's Required
validator message should be:

"Please enter your username."

And not

"Please enter your email address."

If the properties files could support string definitions based on
variation as well as locale then this would be quite easy to do.

At the moment I can work around this using string definitions like:

Please enter your ${label}

and call setLabel on each form component passing in variation dependent
names but the ideal solution would be to specify these labels in a
variation specific way in the properties file.




From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
Sent: Monday, 13 February 2012 8:09 AM
To: users@wicket.apache.org
Subject: StringResources in forms based on 'variation'

I configure StringResources for forms using the FormClass.properties
file and this works well.

Different strings can be provided for lang, locale etc.,

Is it possible to provide a different string based on the markup
'variation'

Yours sincerely,

Chris Colman

Pagebloom Team Leader,
Step Ahead Software


pagebloom - your business&  your website growing together

Sydney:   (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120
Email: chr...@stepahead.com.au
Website:
http://www.pagebloom.comhttp://www.pagebloom.com/>
http://develop.stepaheadsoftware.com
http://develop.stepaheadsoftware.com/>






-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Architectural question

[Bas Gooren]

Chris,

Thanks for your response.

It sounds like the "exposed domain model" is what we are using right 
now. Our current DAOs are what are called Repositories in EDM.
I am investigating moving away from it because of the clear lack of 
layers, which is what brought me to consider DTO's etc. I'm not a big 
fan of building classes just for the sake of it, so I decided to ask 
here how other deal with this.


In your apps, how do you deal with transactions? Since you expose your 
domain models, and have OSIV, where do you begin and commit a transaction?


Also, how do you define your internal api contract?
E.g. in our case we have an Order entity and a Customer entity. Let's 
say we have a business rule that says the total amount of outstanding 
orders has to be within the Customers credit limit (e.g. a number on the 
customer entity).
If we expose the repository directly to the view (wicket), this means 
that it's possible to simple whip up a new Invoice entity, and call 
repository.persist(invoice), thus bypassing any checks.
Since we have a lot (a lot!) of orders, we don't access them as a list 
on the customer, but have a method on the repository 
getOutstandingAmountForCustomer(Customer). Since we don't inject 
repositories or services into our entities, this means the developer 
always has to go through a service layer when saving an invoice.

How do you deal with such situations?

We cannot remove the persist() method from our repository, since we need 
to save the invoice at some point. I guess it's the fact that "sometimes 
you go through the service layer, sometimes you don't" part that bugs me.


Again, thanks for taking the time to bear with me :-)

Op 12-2-2012 21:42, schreef Chris Colman:

It sounds like you have a lot of layers/scaffolding (=high maintenance)
in your design.

The "exposed domain model" pattern was created to avoid all those extra
layers (especially DAOs and DTOs) in recognition of the fact that for
most applications they *feel* redundant and *seem* like code
duplication.

I understand the puritan goals that bring about the adoption of DTOs but
IMHO introducing them forms a slippery slope to "productivity
impedance".

We adopted the Exposed Domain Model (EDM) pattern with "Open
[Session|PersistenceManager] In View" many years ago and haven't created
a DAO or DTO since - and development has been easier, faster and more
maintainable since.

EDM still does provide for Respositories (object search, looks ups,
etc., - where your queries reside) and Services (where you orchestrate
non trivial model changes, updates) but for the most part if the UI is
simply CRUDing a model object we expose that model object and let it
call the setters and getters directly.

We even allow some trivial persistent objects to be instantiated
directly by the UI where that is appropriate. With 'persistence by
reachability' (we use JDO - JPA might also have this) it's not even
necessary to call persist() on the newly constructed instances if they
are reachable by at least one already persisted object.

In certain cases where instantiation of an object graph must be
orchestrated according to some business rules or some constraints
implicit in the model we do either of the following:

1. make the domain class' constructors private and force instantiation
to take place via a static method on the particular class.

2. make the domain class' constructors protected and force instantiation
to take place via a Service provided for the package in which the new
class exists.

It's been working flawlessly for us and our domain model now has over
300 persistent classes. I doubt we would have been able to grow it this
fast if we had the extra development burden of developing and creating
DAO and DTO classes on the way. Also the code base would probably be
close to double what it is today.

Having let our hair down this much we must state that we still are 100%
puritan when it comes to separation of Model and Presentation layer. The
model itself has ZERO dependencies on any UI code and can be compiled
completely independently of the UI.


-Original Message-
From: James Carman [mailto:jcar...@carmanconsulting.com]
Sent: Monday, 13 February 2012 4:40 AM
To: users@wicket.apache.org
Subject: Re: Architectural question

Well setters/getters somewhat go against ddd.  We just have to figure

out

what works for us.  It's all about finding what gets the job done most
effectively.
On Feb 12, 2012 10:45 AM, "Bas Gooren"  wrote:


We already use OSIV, thanks to guice-persist.
This means the read-side of things is rather trivial, and that the

service

and dao layers do need to be aware of the exact data the view needs

(since

lazy loading is possible).

With regard to the write-side of things: we do what you do (call

update

explicitly) right now.

Suppose you are using DDD in a project, how would you go about
constructing and populating a new object? Without DDD my entities

were

mere

containers for data with some val

RE: Wicket 'hook' point for page render timing

[robmcguinness]

log level must be set to debug for
org.apache.wicket.devutils.inspector.RenderPerformanceListener. 


ex. output:
19:14:10.563 DEBUG o.a.w.d.i.RenderPerformanceListener - rendered 'HomePage
page' for 207ms



i'm not sure if this is what you needed but maybe you can use as a guide.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-hook-point-for-page-render-timing-tp4378230p4382458.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: Wicket 'hook' point for page render timing

[Chris Colman]

>-Original Message-
>From: robmcguinness [mailto:robert.mcguinness@gmail.com]
>Sent: Monday, 13 February 2012 11:17 AM
>log level must be set to debug for
>org.apache.wicket.devutils.inspector.RenderPerformanceListener.
>
>
>ex. output:
>19:14:10.563 DEBUG o.a.w.d.i.RenderPerformanceListener - rendered
'HomePage
>page' for 207ms

That RenderPerformanceListener works really well! Awesome - it's exactly
what I was looking for.

I didn't know that existed in Wicket. I was thinking I was going to have
to 'roll my own'.

Within seconds I could tell that something I thought was a bottle neck
isn't at all!

Regards,
Chris

>
>
>
>i'm not sure if this is what you needed but maybe you can use as a
guide.
>
>--
>View this message in context: http://apache-
>wicket.1842946.n4.nabble.com/Wicket-hook-point-for-page-render-timing-
>tp4378230p4382458.html
>Sent from the Users forum mailing list archive at Nabble.com.
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org