Re: T5: Enabling disabled datefield
It works. Thank you very much! Hi, Because you set t:disabled=true to the datefield statically, so in the form submit process, its value would not be updated always. You can dynamically set the 'disabled' like t:disabled=!dateEnabled, then you will get the value. DH http://www.gaonline.com.cn - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Enabling disabled datefield
Hi again!
I know that simple components are not that interesting.
Maybe there is someone who also uses this components and knows why it
doesn't work (or maybe should not work).
Przemysław Wojnowski wrote:
Hi!
Is there a way to submit datefield, which has attribute disabled=true
in template but was enabled using JavaScript on page.
Currently enabling field using JS does nothing and datefield is not
submitted, although it should IMHO.
Or is there some other way to have field disabled by default, but with
possibility of enabling it and submitting its value?
Example:
--- template ---
t:checkbox t:id=enableDate t:value=dateEnabled
onclick=$('date').disabled = !$('date').disabled; /
t:datefield t:id=date t:value=date t:format=-MM-dd
t:disabled=true /
--- page class ---
private Date date;
public Date getDate() { return date; }
public void setDate(Date date) {
log(date, startDate);
this.date = date;
}
In code above setDate() is not called, even though datefield was enabled
using JS.
Regards,
Przemysław Wojnowski
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
T5: Enabling disabled datefield
Hi!
Is there a way to submit datefield, which has attribute disabled=true
in template but was enabled using JavaScript on page.
Currently enabling field using JS does nothing and datefield is not
submitted, although it should IMHO.
Or is there some other way to have field disabled by default, but with
possibility of enabling it and submitting its value?
Example:
--- template ---
t:checkbox t:id=enableDate t:value=dateEnabled
onclick=$('date').disabled = !$('date').disabled; /
t:datefield t:id=date t:value=date t:format=-MM-dd
t:disabled=true /
--- page class ---
private Date date;
public Date getDate() { return date; }
public void setDate(Date date) {
log(date, startDate);
this.date = date;
}
In code above setDate() is not called, even though datefield was enabled
using JS.
Regards,
Przemysław Wojnowski
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Grid#setupDataSource and GridDataSource
Dnia 2009-06-24, śro o godzinie 12:19 -0300, Thiago H. de Paula Figueiredo pisze: Why Grid#setupDataSource() is calculating endIndex and not allowing for GridDataSource to do it? Why GridDataSource#prepare method have startIndex and endIndex parameters and not offset/limit pair? As offset = startIndex and limit = endIndex - startIndex + 1, I think their interchangeable for most scenarios. I'm asking, because if GridDataSource could calculate endIndex (or use limit instead) for itself, then there would be no need to call getAvailableRows() before prepare(), which is a problem (at least IMHO). I guess getAvailableRows() is used for calculating the number of pages and then display the pager. When pager is used, then GDS#prepare() was already called, so getAvaialbleRows() can return correct value. My point is that the current implementation of Grid#setupDataSource() uses getAvailableRows() to calculate exact values for start and end indices. Shouldn't this be responsibility of GridDataSource? Grid#setupDataSource() could pass just logical (exact available rows would be calculated by GDS) values calculated as I wrote in previous post. IMHO this would also allow for GDS to handle rows deletions for itself. This would allow for single-call (those which receive number of available rows, columns definitions, and columns values in one expensive call) datasources to work. Please file a JIRA about this. Maybe we could use some special return value in GridDataSource.getAvailableRows() to indicate that it is not available yet and then call it again after GridDataSource.prepare(), thus solving your problem. IMHO there is no need for special value. It's just matter of the current implementation of Grid#setupDataSource(). For now, to make Grid working with single-call GridDataSource, I had to copy Grid.java only to replace setupDataSource(). Best regards, Przemysław Wojnowski - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Grid#setupDataSource and GridDataSource
2009-06-25 Thiago H. de Paula Figueiredo:
2009/6/25 Przemysław Wojnowski przemyslaw.wojnow...@nask.pl:
My point is that the current implementation of Grid#setupDataSource()
uses getAvailableRows() to calculate exact values for start and end
indices. Shouldn't this be responsibility of GridDataSource?
Nice points in the whole message. :)
One solution would be to create another interface, because Grid needs
to know the number of available rows (regardless if before or after
prepare()) and changing GridDataSource now would break backward
compatibility quite badly.
IMHO there is no need for special value. It's just matter of the current
implementation of Grid#setupDataSource().
You're suggesting the reversal of invokating order of prepare() and
getAvailableRows()? I don't see any way of Grid working without
getAvailableRows(), as it's needed to handle paging.
I think i was misunderstood. I don't want to change any interface,
especially GridDataSource. I'm just writing about current (Tapestry
5.2.0-snapshot) implementation of one method: Grid#setupDataSource().
The source code for this method is as follows:
--- code ---
void setupDataSource()
{
// TAP5-34: (...)
cachingSource = new CachingDataSource(source);
int availableRows = cachingSource.getAvailableRows();
if (availableRows == 0) return;
int maxPage = ((availableRows - 1) / rowsPerPage) + 1;
// This captures when the number of rows has decreased,
typically due to deletions.
int effectiveCurrentPage = getCurrentPage();
if (effectiveCurrentPage maxPage)
effectiveCurrentPage = maxPage;
int startIndex = (effectiveCurrentPage - 1) * rowsPerPage;
int endIndex = Math.min(startIndex + rowsPerPage - 1,
availableRows - 1);
dataModel = null;
cachingSource.prepare(startIndex, endIndex,
sortModel.getSortConstraints());
}
--- code ---
Here getAvailableRows() is used only to calculate start and end indices.
But their exact values (taking into account decreased number of rows)
can (maybe should?) be calculated in implementation of GridDataSource
and then implementation of Grid#setupDataSource() could look like this:
--- code ---
void setupDataSource()
{
cachingSource = new CachingDataSource(source);
int startIndex = (getCurrentPage()-1) * rowsPerPage;
cachingSource.prepare(startIndex, startIndex+rowsPerPage,
sortModel.getSortConstraints());
}
--- code ---
Grid still uses getAvailableRows() but not in setupDataSource() method,
and not before prepare().
Maybe I misunderstood something or not seeing something. In that case I
would like to know what. :-)
Best regards and thanks for response!
Przemysław Wojnowski
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
T5: Grid#setupDataSource and GridDataSource
Hi!
Why Grid#setupDataSource() is calculating endIndex and not allowing for
GridDataSource to do it? Why GridDataSource#prepare method have
startIndex and endIndex parameters and not offset/limit pair?
I'm asking, because if GridDataSource could calculate endIndex (or use
limit instead) for itself, then there would be no need to call
getAvailableRows() before prepare(), which is a problem (at least IMHO).
Then Grid#setupDataSource() could look like this:
void setupDataSource()
{
cachingSource = new CachingDataSource(source);
int startIndex = (getCurrentPage()-1) * rowsPerPage;
cachingSource.prepare(startIndex, startIndex+rowsPerPage,
sortModel.getSortConstraints());
}
This would allow for single-call (those which receive number of
available rows, columns definitions, and columns values in one expensive
call) datasources to work.
Best regards,
Przemysław Wojnowski
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T4.1: remove ASO from session
Thanks for response.
I've added issue: https://issues.apache.org/jira/browse/TAPESTRY-2740
Your workaround works. Thanks!
--- workaround ---
@InjectObject(service:tapestry.state.SessionScopeManager)
public abstract StateObjectPersistenceManager getStateManager();
public void someMethod() {
if (getStateManager().exists(foo)) {
// ASO is in the session
} else {
// ASO was removed
}
}
---
Regards,
Przemysław Wojnowski
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
