Paul,
I was wrong about applying style=.. to dataScroller buttons. Your style
works.
With Ajax... I will try to implement some functionality on me prototype
pages, may be next week.

thanks
vlad


On 7/6/07, Paul Iov <[EMAIL PROTECTED]> wrote:

vlad10 schrieb:
> Paul,
> I hope you did not miss my email from late yesterday with 6 items.
> I just discovered something in addition to this discussion. I have a
page
> with a dataTable but no scroller, and I've noticed, that my method for
> accessing DB was called twice right on start. That means the bug with
dup
> calls is hidden in dataTable rather than dataScroller.
>
> vlad
>
>
Hi Vladimir...
I was just writing the answer, so I'm replying now to this message:
---

It was a really big challenge to implement this approach right and I'm
glad that my experience can help someone else - I've thinking to be one,
who are using JSF for something more then simple "Hello world"-play
around ;) Regarding your questions:

1+2+4
here's my JSP again:
<ac:ajaxDataScroller
           rendered="#{Recherche.data.rowCount gt 0}"
           id="scroller"
           for="tblData"
           fastStep="10"
           renderCurrentAsText="false"
           maxPages="9"
/>

           <f:facet  name="first">
               <h:graphicImage
value="constellations/images/dreieck_links.gif" *style="border:none"
*alt="first"/>
           </f:facet>
           <f:facet name="last">
               <h:graphicImage
value="constellations/images/dreieck_rechts.gif" style="border:none"
alt="last"/>
           </f:facet>
           <f:facet  name="next">
               next
           </f:facet>
           <f:facet  name="previous">
               prev
           </f:facet>
</ac:ajaxDataScroller>
My red arrows ARE first/last. If you wish to set the border, it should
be something like style="border: #FFAA00 1px solid;"
I've also added next/prev as text in the same scroller and then one more
scroller with buttons only for the same DataTable... and all still works
as expected.
It should be no difference, because the only things the scroller perform
with DataModel is to call ((UIData) component).*setFirst*() on
navigation to new page and to obtain *getRowIndex*()/*getRowCount*().
The rest is in responsibility of DataModel implementing class itself.

The multiple calls to fetchPage() are harmless since the doFetchPage()
handles the caching correct. I'm not more familiar wit t:DataScroller
source code (it was few months ago), but I suspect the most of them are
caused by DataTable, not by DataScroller. I'm also not sure if reporting
this bug(?) makes any sense. The best bet would be IMO to redesign this
component 'from scratch'.

Regarding AJAX. There are few good and stable enough implementations.
Sure, you can program all manually with JS/DOM, but if you choose to use
some framework, you don't have to deal with XMLHttpRequest directly. It
may be a bit oversized for one or to pages with few AJAX-like gimmicks
but is very useful for big project. I'm using AJAX4JSF (aka A4J, by
Exadel, now moved to JBoss) and some native JS libraries like
Scriptaculous. (Early denoted ac:AjaxDataScroller is based on A4J
commandLink too, so you need this library to get it work.) Some of
Incubator/Tomahawk components as well Tobago (formerly Oracle's
ADF-Fases) as well utilize AJAX in diverse way.

regards,
paul

Vladimir Isakovich schrieb:
> Paul,
> many thanks for your answers.
>
> 1. Interestigly enough, after the warning the border is  still
> applied. If I try to do the same with style=..., there is no effect.
> this has nothing to do with the data fetching.
> 2. I have a guess about two calls to fetchPage() in the DataModel. May
> be it's because we have 2 UIComponents called DataScroller (one with
> buttons and another with the message). Shuld it be posted as a bug on
> dataScroller? I've seen the defects page on myFaces, but not familiar
> with the procedure of addin to that list.
> 3. I've got it why you have your pageSize being analized and used in
> getDataModel(), your page explains it. I'll try to implement the same
> with an additional inputText.
> 4. I also noticed on your page - the dataScroller has just 2 buttons
> plus numbers in between. This way your strategy of fetching data
> chunks should work. I am using the "standard" scroller which has in
> addition fast forward/backward and first/last buttons, and in this
> case I think I'm better of calling DB every time (I've no way of
> predicting what page will be requested next).
> 5. Probably next thing I'll try to implement: edit/delete/add, and
> after that I'm planning to implement Ajax datascroller. It's not a
> good user experiense, when the whole page gets re-rendered on every
> action.
> 6. Although I've experience with javaScript, at least when I compare
> myself with the java developers I've worked with, but I've never tried
> using XmlHttpRequest. I have this book: 'Pro JSF and Ajax', but it was
> a diappointment after loading and gettin running their example to find
> out that it's based on some proprietary jars. Since you're using this
> ajax dataScroller, could you please enlight me on any existing
> standard for ajax (are there some 'standard' jars I can use as a base
> of my app)?
>
> thanks, vlad
>
>
> On 7/5/07, *Paul Iov* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>     Well... just a bit refining
>     Vladimir Isakovich schrieb:
>>
>>     Jul 5, 2007 1:12:09 PM com.sun.facelets.tag.jsf.ComponentRule
>>     warnAttr
>>     WARNING: /web/sec/examples/largeTableScroller.xhtml @104,85
>>     border="1" Property 'border' is not on type:
>>     org.apache.myfaces.component.html.ext .*HtmlGraphicImage*
>>
>>     2. I also can see a warning...
>>
>     It's correct. The old good border="0" for image is deprecated with
>     HTML4. We should use CSS instead.
>
>
>


> Paul Iov wrote:
>
>> Hi Daniel,
>>
>> have you read my long post about how the data are handled in internal
>> storage? Do you have the same approach and what do you mean exactly
with
>> "delete"? If you just delete the record from DB (i.e. via JDBC/SQL),
you
>> have to set also _invalidated flag in my class, to force the internal
>> storage to be reloaded. (It's not especially efficient but it should
>> work.) If you have implemented your own delete(_whatever_) method in
>> this class, this method have to delete the ID from internal storage and
>> then ensure, that the page will be refetched next time (i.e. with some
>> extra boolean flag; in my code I just store the last ID-list generated
>> during fetching of page and if it becomes changed [something was
>> deleted/sorted in internal storage], I force the page to be refetched).
>> This should be the better way, since after delete/edit of an item only
>> the current page of data will be refetched - not the whole dataset AND
>> the current page. ...and first after this comes the issue with
>> dropScroller :). Probably, you don't need then this method at all.
>>
>>
>> daniel ccss schrieb:
>>
>>> Hi Paul, I put your code in my backing_bean and call the method
>>> dropScroller(String dataTableId) after the delete method was called, I
>>> send to this method the id of the data table:
>>>
>>>                 <t:dataTable id="data" styleClass="scrollerTable" ...
>>>
>>>
>>> But the dataTable doesn´t update, in my console I recived the message:
>>> " dropScroller called" but nothing happen. What else do I should do,
>>> or what I'm doing bad.
>>>
>>> Also:
>>> I guess Daniel, you are using event listener in your backing bean to
>>> edit data directly in PagedList? It's the only way to have actual copy
>>> displayed without to reload this page.
>>>
>>> Yes, Paul in fact I´m doing that, and, as Vladimir, I call the DB each
>>> time the PageData change. When I didn´t have your improved class
>>> PagedList, it works fine, since the fetch was doing many times for
>>> each action and the data update in the DataTable. For that I was
>>> thinking in some way put another condition on your filter for the
>>> fetch where after I called the add/delete/edit method put that
>>> variable in true and enter to the if to do the fetch, because I see
>>> that when I click in the page number (a fetch is doing) the data
>>> update in the DataTable. I hope your solution works for me It looks
>>> pretty nice.
>>>
>>> On 7/5/07, *Vladimir Isakovich* <[EMAIL PROTECTED]
>>> <mailto:[EMAIL PROTECTED]>> wrote:
>>>
>>>     Paul,
>>>     many thanks for your answers.
>>>
>>>     1. Interestigly enough, after the warning the border is  still
>>>     applied. If I try to do the same with style=..., there is no
effect.
>>>     this has nothing to do with the data fetching.
>>>     2. I have a guess about two calls to fetchPage() in the DataModel.
>>>     May be it's because we have 2 UIComponents called DataScroller
>>>     (one with buttons and another with the message). Shuld it be
>>>     posted as a bug on dataScroller? I've seen the defects page on
>>>     myFaces, but not familiar with the procedure of addin to that
list.
>>>     3. I've got it why you have your pageSize being analized and used
>>>     in getDataModel(), your page explains it. I'll try to implement
>>>     the same with an additional inputText.
>>>     4. I also noticed on your page - the dataScroller has just 2
>>>     buttons plus numbers in between. This way your strategy of
>>>     fetching data chunks should work. I am using the "standard"
>>>     scroller which has in addition fast forward/backward and
>>>     first/last buttons, and in this case I think I'm better of calling
>>>     DB every time (I've no way of predicting what page will be
>>>     requested next).
>>>     5. Probably next thing I'll try to implement: edit/delete/add, and
>>>     after that I'm planning to implement Ajax datascroller. It's not a
>>>     good user experiense, when the whole page gets re-rendered on
>>>     every action.
>>>     6. Although I've experience with javaScript, at least when I
>>>     compare myself with the java developers I've worked with, but I've
>>>     never tried using XmlHttpRequest. I have this book: 'Pro JSF and
>>>     Ajax', but it was a diappointment after loading and gettin running
>>>     their example to find out that it's based on some proprietary
>>>     jars. Since you're using this ajax dataScroller, could you please
>>>     enlight me on any existing standard for ajax (are there some
>>>     'standard' jars I can use as a base of my app)?
>>>
>>>     thanks, vlad
>>>
>>>
>>>     On 7/5/07, *Paul Iov* <[EMAIL PROTECTED]
>>>     <mailto:[EMAIL PROTECTED]>> wrote:
>>>
>>>         Well... just a bit refining
>>>         Vladimir Isakovich schrieb:
>>>
>>>>         Jul 5, 2007 1:12:09 PM com.sun.facelets.tag.jsf.ComponentRule
>>>>         warnAttr
>>>>         WARNING: /web/sec/examples/largeTableScroller.xhtml @104,85
>>>>         border="1" Property 'border' is not on type:
>>>>         org.apache.myfaces.component.html.ext .*HtmlGraphicImage*
>>>>
>>>>         2. I also can see a warning...
>>>>
>>>>
>>>         It's correct. The old good border="0" for image is deprecated
>>>         with HTML4. We should use CSS instead.
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>


Reply via email to