myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Bohmann <bernd.bohm...@atanion.com>
Subject Re: [core] performance: performance hints
Date Tue, 26 Apr 2011 16:12:05 GMT
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.koci@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.koci@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.
>>
>>
>
>
>

Mime
View raw message