Kanaalinvoeren versus embed-bestanden

Ik heb een soort van dilemma en omdat ik nooit echt kanalen in EE heb gebruikt (ja, dat is vreemd), behalve voor een bloggedeelte was ik benieuwd wat het echte voordeel is. Ik zie het gewoon niet.

Laat me een voorbeeld geven en misschien kan iemand met meer ervaring dit beantwoorden met een technische benadering over waarom ze beter zijn.

Ik moet documentatie maken. Dus neem aan dat /help een (sjabloon) is die vervolgens bijvoorbeeld een andere intro-sjabloon insluit. Dus nu heb je /help/intro en natuurlijk schrijf je je gebruikelijke help-documentatie op intro of andere sjabloonbestanden.

In de index van de groepssjablonen " help " kan ik alleen maken als segmenten oproepen, bijvoorbeeld:

{if segment_3 == 'to-super-product'}embed="help/some-other-template "}{/if}

En nu hebben we iets aardigs als:

example.com/help/intro/to-super-product

Nu is het natuurlijk de juiste manier om kanaalinvoer voor elk artikel te gebruiken, dus in plaats van een segment_3 te gebruiken, maakt u voor elk hoofdstuk een kanaalingang.

Het probleem met die aanpak is dat je nu beperkt bent tot de beperkingen van de kanaalinvoervakken. Tenzij u een plug-in van Ellis Lab gebruikt, kunt u EE-variabelen niet meer in een inhoud gebruiken en zij raden het voor beveiliging af.

Met de sjablonen-aanpak zou ik bijvoorbeeld een variabele genaamd {version_number} kunnen hebben en deze gebruiken in al mijn documentatie. Ik verander die variabele en die is overal veranderd. Ik kan alles bewerken en ontwerpen zoals ik wil met HTML en de Help-artikelen zijn volledig dynamisch.

Maar als u de kanaalinvoerroute kiest, bent u gedwongen om de inhoud statisch te maken. Je kunt de {version_number} niet meer gebruiken, of als je kleuren, lettertypen of andere dingen breed wilt maken, kun je dit niet doen tenzij je naar het Expression Engine regelpaneel gaat en elk kanaalitem individueel bewerkt.

Ik ben verrast dat iedereen kanalen gebruikt als het minderwaardig lijkt. Het enige voordeel dat ik hier zie, is als je gebruikers die geen codeerder/ontwerper zijn, moet toestaan ​​om de inhoud te bewerken en je niet wilt dat ze een code verprutsen. Maar om dezelfde visuele effecten op een pagina te bereiken, zou u veel verschillende kanaalvermeldingen moeten maken die ze een voor een moeten bewerken.

Wat ben ik hier verkeerd aan het doen? Het bewerken van HTML-bestanden lijkt schoner en ik kan ze dynamisch maken versus statische kanaalitems. Als ik statisch bedoel, bedoel ik de inhoud erin. Bijvoorbeeld het wijzigen van lettertypen, notities, versienummers, productnamen ...

UPDATE:

Ik gebruik het niet om statische HTML te maken en dit is precies wat kanalen doen. Wanneer u inhoud van een kanaal ontvangt, wordt die inhoud van het HTML-blok beperkt door alleen de HTML die iemand heeft opgeslagen via het configuratiescherm.

Laat me proberen dit te verduidelijken. Ik laat niemand anders de inhoud nu bewerken. Ik maak de inhoud. Misschien zie ik daarom vandaag weinig gebruik van kanalen. Ik kan volledig begrijpen hoe nuttig ze zijn om inhoud van code te scheiden als je andere mensen toestaat om inhoudstekst of afbeeldingen naar pagina's te bewerken of toe te voegen.

Laat me een eenvoudig voorbeeld maken. Zie je het gele vakje op je antwoord dat je hebt aangehaald? Laten we aannemen dat dit wordt getrokken uit een kanaalinvoer. Die tekst is alles wat je krijgt in termen van opmaak. Als u letters naar BB wilt wijzigen of iets dynamisch wilt wijzigen met CSS, kunt u dit niet doen.

Maar als dezelfde tekst direct wordt opgeslagen in een sjabloon, en ik de juiste EE-variabelen heb rond de inhoud of code die ik wil, kan ik deze direct wijzigen, site-breed. Dit is precies waarom EE zo geweldig is. Je kunt sites dynamisch maken. Maar kanalen zijn statische inhoud. Ja, u kunt de invoer beperken, sorteren op datum, categorie en vele andere dingen, maar de inhoud die u van een kanaalitem ontvangt, is vast en beperkt door de velden die u via het configuratiescherm hebt toegestaan.

Ik ben niet nieuw voor EE. Ik heb het sinds versie 2 gebruikt, maar ik hoefde nooit kanalen te gebruiken omdat ik me gedwongen voel door ze te gebruiken, alleen maar om rechtstreeks sjablonen te bewerken die schoner en sneller lijken. Alle voorbeelden en tutorials zijn hetzelfde. Ze laten zien hoe je een nieuwssectie, een blog of andere eenvoudige blokken met tekstvermeldingen kunt maken die je zou toevoegen aan een database. Niemand lijkt een zeer geavanceerd gebruik of casusscenario te maken. Ik kan ook zien dat kanalen nuttig zijn in dat opzicht, als je veel items moet invoeren die vergelijkbaar zijn en ze dan moeten classificeren of sorteren. In dat geval is een kanaalinvoer een database-item, dus het is erg handig voor gegevensorganisatie/classificatie. Maar ik verwijs naar unieke webpagina-inhoud die heel anders is, maar je moet deze nog steeds automatisch of dynamisch wijzigen op een site.

0
ja ru de

1 antwoord

Ik ben erg in de war door je vraag, maar ik ga een poging doen om een ​​aantal basisbegrippen te verduidelijken waarvan ik denk dat je ten onrechte aanneemt over een commercieel kwaliteit CMS (content management system) zoals ExpressionEngine en CMS's in het algemeen (mogelijk, niet proberen te zeggen dat je niet weet wat je doet).

Allereerst is dit een contentmanagementsysteem. Het is geen statische site-generator of een systeem voor het implementeren van platte html-inhoud. Het is een CMS. Het basisidee achter een CMS is dat u een functioneel systeem hebt dat een verbinding tot stand brengt tussen gegevens die in een database leven en hoe u de uitvoer van die gegevens via sjablonen uitdrukt en beheert. CMS's voegen ook functionaliteit toe zoals gebruikersregistratie en dynamische routing, enzovoort. EE doet dit.

Bijvoorbeeld met de sjablonenbenadering zou ik een variabele genaamd kunnen hebben   {version_number} en gebruik dit op al mijn documentatie, ik verander dat   variabel en het is overal veranderd. Ik kan alles bewerken en ontwerpen   zoals ik wil met HTML en de help-artikelen zijn volledig dynamisch.

     

Maar als u de kanaalinvoerroute kiest, bent u beperkt tot maken   de inhoud statisch. U kunt het {version_number} niet meer gebruiken of zo   Als u kleuren, lettertypen of andere dingen wilt veranderen, kunt u de breedte ervan vergroten   doe dit tenzij u naar het Expression Engine configuratiescherm gaat en het bewerkt   elk kanaalitem afzonderlijk.

OK ... Hier raak ik echt in de war.

Het systeem voor gegevensbeheer in kanalen en hoe je sjabloon helemaal niet gebroken is. Ze werken geweldig samen. Het doel van een dergelijk systeem is om ontwikkelaars in staat te stellen een divers CMS te maken waarmee inhoudeditors hun werk kunnen doen zonder HTML- of CSS- of JS- of EE-sjablooncode te hoeven weten.

U kunt bijvoorbeeld de versiebeheer van uw documentatie beheren via EE-categorieën en kanalen. De EE-documentatie doet dit zonder probleem. En het doet het met:

-Differente stijlen van EE2 tot EE3/EE4 docs
-Different architectuur in heel het land - Mogelijk verschillende zoektoepassingen, afhankelijk van de doc-versie die u bekijkt

Ik blijf zeggen dat ik in de war ben omdat EE een prima systeem is voor het ontwerpen en implementeren van documentatie. Ik heb het gedaan en heb andere (veel meer getalenteerde) ontwikkelaars het ook zien doen.

Ik denk dat je de standaarddocumenten op dit systeem opnieuw moet doorlopen als je het wilt blijven gebruiken. Als u een platte site zonder inhoudscontrole wilt, is dit niet de juiste keuze, omdat u veel te weinig gebruikmaakt van de mogelijkheden.

Bewerk uw vraag met een beetje meer informatie over wat uw site probeert te doen. We willen u helpen, maar vanuit uw vraag kan ik alleen maar aannemen dat u niet weet wat u nodig hebt of dat u niet weet hoe u EE op de juiste manier kunt gebruiken.

2
toegevoegd