2010-07-29 3 views
6

Ich möchte ein Facelet dynamisch auswählen, um ein Element in meiner Datenliste zu rendern. Der erste Versuch wäre:Dynamische UI: in ui einschließen: wiederholen. Gibt es eine einfache Lösung?

 
<ui:repeat value="#{panels}" var="panel"> 
    <ui:include src="#{panel.facelet}"> 
</ui:repeat> 

Aber es wird seit src von ui nicht funktionieren: include zu früh ausgewertet. Die Facelet-Informationen sind wirklich dynamisch, daher kann ich c: forEach nicht verwenden (nicht wirklich empfohlen, sie mit Facelets zu mischen). Ich schätze, es läuft alles darauf hinaus, eine komponentenbasierte ui zu finden: Alternative einschließen.

Gibt es so etwas oder muss ich mein eigenes schreiben?

+0

Wir haben weiterhin mit dem gleichen Problem seit Jahren zu kämpfen. Ich frage mich, ob Sie jemals eine bessere Lösung mit JSF 2 gefunden haben.Wenn nicht, könnten Sie Ihre benutzerdefinierte Lösung teilen? – cyberoblivion

+0

@cyberoblivion Wir haben unsere eigene Include-Komponente und angepasste UIRepeat implementiert, um damit zu arbeiten - hauptsächlich um mehrere Verschachtelungsebenen zu ermöglichen. Es funktioniert immer noch in unseren Produktionssystemen. Aber wir sind trotzdem von JSF weggezogen. – mrembisz

+0

also ist die Lösung nicht etwas, das für jemand anderen nützlich wäre oder Sie den Code nicht teilen dürfen? Ich bin sehr an dem Code interessiert. – cyberoblivion

Antwort

2

c: forEach wird es lösen, warum können Sie es nicht verwenden?

Interessanter Artikel über dieses Thema: http://www.ilikespam.com/blog/c:foreach-vs-ui:repeat-in-facelets

+0

Danke, aber c: forEach wird einmal ausgewertet, wenn die Ansicht erstellt wird. In meinem Fall kann sich der Inhalt von # {panels} ändern, während der Benutzer mit der Seite interagiert. – mrembisz

+0

Dies als eine Antwort zu markieren: Es wird nicht für mich arbeiten, hauptsächlich wegen der Auswirkungen auf die Leistung, aber für die meisten in Ordnung sein wird. Verwenden von benutzerdefinierten dynamischen Include für jetzt. – mrembisz

0

Ich erinnere mich, zu versuchen, etwas ähnliches mit einem benutzerdefinierten Tag und FaceletHandler usw. Am Ende all die kleinen Rendering-Zeit Probleme es nicht die Mühe wert zu tun haben. Wohlgemerkt, ich war (und immer noch: - (...) mit facelets für jsf 1.1, also nicht sicher, ob dies in den späteren Versionen besser ist.

Wie dynamisch/wie viele verschiedene Facelets müssen Sie haben behandeln? der Grund, warum ich frage ist, dass Sie könnte (ein Begriff aus der Compiler-Assistenten zu leihen) Ihre Schleife entrollen. Statt

<ui:repeat value="#{panels}" var="panel"> 
    <ui:include src="#{panel.facelet}"> 
</ui:repeat> 

Sie

tun konnte
<custom:panelOneFacelet rendered="#{hasPanel1}" /> 
<custom:panelTwoFacelet rendered="#{hasPanel2}" /> 
<!-- etc... --> 

Und in Ihrem Facelet, Sie hätte etwas wie:

<c:if test="#rendered" > 
    <!-- EVERYTHING IN THE FACELET HERE!!!--> 
</c:if> 

Diese Art von Low-Tech- Ansatz ist für einen kleinen kontrollierten Satz in Ordnung, aber wenn Sie einen sehr großen Menge wechselnden Satz von facelets haben diese möglicherweise nicht.

Darf ich fragen, warum, b/c manchmal mit einem Verständnis für die High-Level, kann SO Gurus vorschlagen viel einfacher Ideen zur Durchführung des gleichen Ziel

+0

Grundsätzlich rendern wir ein Business-Formular, das uns als Baum von Datenfeldern zur Verfügung gestellt wird. Was Sie hier beschreiben, war unser erster Versuch, aber es stellte sich heraus, dass es sehr ressourcenintensiv war, da wir in jedem Knoten eine ganze Reihe möglicher Rendering-Optionen hatten. Wir haben am Ende unsere eigene include-Tag + -Komponente implementiert, die gut funktioniert, aber aufgrund der Komplexität und der jsf-Interna sehr mühsam zu warten ist. Wir haben das vor fast 3 Jahren gemacht und planen nun den Umzug nach jsf2. Ich hatte gehofft, dass zu diesem Zeitpunkt eine alternative Alternative auftauchen würde. – mrembisz

+0

Hmmm .. nicht sicher, ich verstehe ... so haben Sie wie Bibliothek {Ort, Name, Liste Bücher} wo Buch {Name, isbn, Autor} wo Autor {Name, Alter, ..} So ähnlich? Und Sie möchten diese Art von Struktur bekommen, um einen Baum von Formularfeldern zu erzeugen? ... Ich muss das falsch haben, oder? .. Das erscheint mir viel zu komplex, ich würde das alles auf verschiedene Formen und Bohnen reduzieren etc ... –

+0

Sie haben es richtig gemacht, das ist genau das, was wir haben und wir kennen die Datensatzstruktur erst zur Laufzeit. Wie gesagt, wir haben eine funktionierende, aber recht komplexe Lösung. Ich möchte die Möglichkeit untersuchen, unsere benutzerdefinierte JSF Include-Logik fallen zu lassen. – mrembisz

4

Ich glaube, ich habe festgestellt, dass relativ einfache Lösung Sie haben gesucht.

Ich begann auch mit einem UI: Include in einem UI: wiederholen Sie wie Ihres, aber ich akzeptierte, dass ich ac: forEach verwenden musste, und das C: forEach funktionierte großartig, um dynamisch einen anderen Satz von Xhtml/Komponenten zu bekommen schließe sogar mit der Benutzerinteraktion ein, Dinge in der Ansicht zu ändern, wie ich denke, dass du hast. Es sah wie folgt aus:

<c:forEach var="thing" items="#{view.things}"> 
     <ui:include src="#{thing.renderComponent}"> 
      <ui:param name="thing" value="#{thing}"/> 
     </ui:include> 
</c:forEach> 

jedoch meine ui: param nicht funktionierte - jede Komponente I enthalten war das gleiche „Ding“ bestanden/Objekt, auch wenn wir erfolgreich verschiedene Dinge benutzt hatte/Objekte dynamisch sind verschiedene Komponenten.

Das ist, wenn ich this Post gefunden habe, die mich inspirierte, um meine ui: in einer f: Unteransicht einzuschließen. Und jetzt funktioniert alles super mit dem folgenden Code:

<c:forEach var="thing" items="#{view.things}" varStatus="loop"> 
    <f:subview id="thing_#{loop.index}"> 
     <ui:include src="#{thing.renderComponent}"> 
      <ui:param name="thing" value="#{thing}"/> 
     </ui:include> 
    </f:subview> 
</c:forEach> 
+1

Danke, Mann! f: subview war die Antwort für mich! – hbobenicio

Verwandte Themen