Hello Marin,
I don't see any problems to include this feature into MyFaces Core.
I don't think this breaks the specification:
<h:dataTable ....>
<f:attribute name="readonly" value="true" />
</h:dataTable>
Maybe we should also consider:
<h:dataTable ....>
<h:column >
<f:attribute name="readonly" value="true" />
</h:column>
</h:dataTable>
>From my point of view you should commit your suggestion to 1.1.x,
1.2.x, 2.0.x and 2.1.x.
Regards
Bernd
On Tue, Apr 26, 2011 at 5:13 PM, Martin Koci
<martin.kocicak.k...@gmail.com> wrote:
> Hi,
>
> Leonardo Uribe píše v Po 25. 04. 2011 v 12:45 +0200:
>> Hi
>>
>> 2011/4/19 Martin Koci <martin.kocicak.k...@gmail.com>
>> Hi,
>>
>> is it possible to introduce performance hints in myfaces-core?
>> Hints
>> similar to javax.faces.component.visit.VisitHint but related
>> to
>> performance improvements. Example:
>>
>> For dataTable like:
>> <a:dataTable
>> <a:column>
>> #{aExpression}
>>
>> it's completely unnecessary to save per-row state. Currently
>> there is no
>> elegant way how to do read-only table (state per-row is always
>> maintained). If user wants (fast) readOnly table, he/she must
>> extend
>> UIData and re-implemenent setRowIndex method. But hint say
>> "org.apache.myfaces.core.UIData.saveRowState"=false can solve
>> it
>> elegantly - if present (in component.getAttributes()) UIData
>> skips
>> row-state-saving and restoring methods entirely.
>>
>>
>> Unfortunately, we can't do anything like that on default UIData
>> implementation
>> (it could breaks backwards behavior). I think we could include a
>> property
>> on tomahawk t:dataTable called "readOnly", that just skip all that
>> code
>> related to save/restore for rows. That could be better, and it has
>> sense to
>> put in tomahawk, because after all that is the right location for
>> extend
>> default jsf components.
>
> Yes, this is one point of view and I agree with that "custom behaviour
> belongs into custom component". I did exactly the same for my component.
>
> But there are other topics to consider:
>
> 0) simple presence of performance hints in core does not break the
> compatibility : the *usage* of that hint can break the compatibility -
> so as usual, user must know what that parameter means and what it can
> cause.
>
> 1) I think JSF implementation can break the specified functionality:
> myfaces did it already with elResolvers sorting for example. But the
> default must be always false for 100% compatibility with JSF
> specification.
>
> 2) The hint technique is very common : another example from Java EE is
> world JPA Query.setHint
>
> 3) Hints are a simple way to realize something "this should be in core"
> but because of slow specification release cycle, you must wait a year or
> two to get it officially specified in public API.
>
> 4) Ease of usage: for example, if you have only one readonly table in
> whole project, creation of custom component for that purpose is an
> overkill: simple <f:attribute name="oam.readOnly" value="true" /> is
> much easier.
>
> 5) Internet is full of "JSF is slow". Although I know that is completely
> untrue, "hinting the core" for more performance is a easy way which
> allows users to express all they need without additional dependencies.
>
>
> So, do you think we really can't put this feature in core? I mean the
> "hints feature" generally, not readonly UIData - that was only an
> example.
>
>
> Regards,
>
> Kočičák
>
>>
>> Anyway, I think it is possible to do some work on UIData to make it
>> perform
>> faster and better.
>>
>> Lifespan of those hints can be request
>> (faceContext.attributes) or view
>> (component.attributes)
>>
>> I don't think in this case it applies, but any configuration param for
>> a view
>> should be on a tag like f:view or something similar.
>>
>> regards,
>>
>> Leonardo
>>
>>
>>
>> WDYT?
>>
>> Regards,
>>
>> Kočičák
>>
>>
>> See https://issues.apache.org/jira/browse/MYFACES-3111 too.
>>
>>
>
>
>
