Drupal satura un sistēmas vadība no ārēja risinājuma

j2b Fri, 01/06/2012 - 12:05

Man gan ir savs viedoklis šajā kontekstā, bet lai nenosliektos uz kādu jau esošu manu domu gājienu, pieņemšu, ka to neizklāstīšu.

Saskāros ar vienu īpatnēju klienta pieprasījumu, kur gribētu uzzināt Jūsu viedokli vai domas (iespējams, risinājumus).

<strong>Pamatinformācija:</strong>
Kādam uzņēmumam X ir iepriekš izstrādāta iekšēja web aplikācija, kas nodrošina biznesam nepieciešamās funkcijas. Līdz galam šī sistēma viņus neapmierina, un uzņēmums meklē risinājumus, kādā veidā šo sistēmu attīstīt (iespējams pārveidot). Daļā jautājums ir arī par frontend izveidi - publiska lapa, kurā ir publisks kontents, kā arī tā paredz iespējas ārējiem reģistrētiem lietotājiem tajā autentificēties, lai saņemtu sev specializētu un pieskaņotu saturu/darbības. Protams, arī lietotāju reģistrācija.

Šajā kontekstā man nav izdevies pārliecināt uzņēmumu X par backend risinājuma migrēšanu uz Drupal. Un var būt arī labi. Taču ir interese par frontend risinājuma izpildi uz Drupal. Tik tālu viss ir OK, bet...

<strong>Klienta prasības</strong>
Pēc diskusijām, klients nav gatavs ieviest uzņēmumā atsevišķu platformu, kura būtu atsevišķi jāmenedžē, gan pats Drupal, gan arī tā saturs un lietotāji (drīzāk vēlas, lai tur nekas nebūtu jādara - uzliek un viss). Viņš vēlas izmantot Drupal tikai satura attēlošanai un komunikācijai ar klientu.

Prasība ir panākt risinājumu, ka gan Drupal saturs, gan pats Drupal tiek vadīts no esošās klienta web aplikācijas.

<strong>Jautājumi, kas nodarbina manu prātu</strong>
Negribētu saskarties ar viedokļiem, ka klients ir "koks", kā arī gribētu aicināt skatīties uz problēmu ar mērķi to atrisināt, nevis definēt, ka tas nav iespējams.

Satura vadību varētu mēģināt izpildīt ar <a href="http://drupal.org/project/services">Services</a&gt; moduļa palīdzību. Kā alternatīvu izskatīju arī jautājumu, ka Drupal vidē tiek izveidota sašaurinātas iespējas vadības konsole (interfeiss), kuru varētu embedēd lokālajā web aplikācijā ar iframe palīdzību, tādā veidā itkā slēpjot to, ka Drupal patiesībā tiek menedžēts pats par sevi. Taču paceļas jautājumi par Single Sign On, lietotāju tiesībām, un datu dublēšanos, jo no sākuma dati (raksts, par piemēru) būtu veidojams tajā lokālajā aplikācijā, kur pēc tam ar web servisu palīdzību tas tiktu novirzīts uz Drupal. Publicēšanas un piekļuves tiesības būtu menedžējamas caur lokālo aplikāciju, kur jau ir ieviests pietiekoši nozīmīgs tiesību kontroles mehānisms, bet tas ir pieejams datubāzes līmenī - nav LDAP vai jebkādu citu externālu autentifikācijas mehānismu, kā arī nav vēlmes/plānu tādus ieviest.

<ul>
<li>Vai kāds varētu padalīties ar savu redzējumu šī jautājuma risināšanai?</li>
<li>Vai kāds ir saskāries ar <a href="http://drupal.org/project/services">Services</a&gt; moduļa konfigurācijām un risinājumiem?</li>
<li>Vai ir bijuši kādi eksperimenti/mēģinājumi panākt paša Drupal un satura vadību ar ārējiem tūļiem?</li>
<li>Vai vispār tas pasākums izskatās reāls, ja neņem vērā potenciālo apņemšanos pārrakstīt lokālajā aplikācijā Drupal funkcijas un iespējas, tikai tādēļ, lai izpildītu klienta uzdevumu?</li>
</ul>

Būtu ieinteresēts diskusijās arī par daļēju risinājumu viedokļiem, vai arī linkiem uz kādu risinājumu analīzi, tajā skaitā potenciāliem drošības caurumiem, ja tādi varētu pastāvēt. Zinu, ka jautājums ir plašs, bet ar kaut ko ir jāsāk. Pateikt - nē var vienmēr, bet var būt tomēr ir kāds risinājums? :)

saturs radīsies tikai no intraneta vai arī no extraneta arī? ja tā, tam būs jānonāk intranetā? esmu strādājis ar servisiem (gan ar services 2, gan services 3 (REST)), bet tikai lasīšanas režīmā un virzienā no drupal uz āru.
Oriģinālais pieprasījums bija saistīts ar to, ka viss saturs, kas parādās frontend (extranet), tiek vadīts no intranet. Tā kā pārrakstīt jebkuru funkciju nav jēgas, jo faktiski frontendā būtu tikai vienreiz konfigurētā info + vienkārši jaunumu raksti, tad tas samazina potenciālo darba apmēru. Vienkārši satura publicēšanai domāju, ka Services varētu būt OK, taču tas ieviestu datu dublēšanu (frontend/backend), un papildus nepieciešamību kontrolēt datu sinhronizāciju. Savādāk to pašlaik neredzu. Kopumā atbildot uz pirmo jautājumu - domāju, ka saturam ir jābūt redzamam gan extra, gan intra netā. Tikai dažādās vidēs, jo intranets ir plānots ne uz Drupal. Vai Services risinājumi varētu palīdzēt nodrošināt ārēju lietotāju autentifikāciju pret citu (ne Drupal) MySQL datubāzes tabulu?
lietotāju autentifikācijai varētu derēt šis materiāls: http://drupal.org/node/809430 drupal problēma ar intranet un extranet, ja tie dala vienu un to pašu saturu, varētu būt tāda ka ar node/X var piekļūt saturam kas nav paredzēts. Tad jāievieš speciālas permisijas uz satura veidiem vai konkrētu saturu. To noteikti nedrīkst piemirst. Servisus un node.create piemērus var atrast šeit: http://drupal.org/node/736522 (Services 3 plānā dokumentācija) Veidosi intranetam ne-drupal saitu? Kādēļ drupal tieši satura attēlošanai?
Paldies, Jāni, par linkiem. Pielikšu to saviem bookmarkiem. Pašlaik nav īsti skaidrs, cik liela ir tā jēga vai cik pamatota ir pasūtītāja vēlme vadīt Drupal un Drupal saturu no ārējas custom vides. Tādēļ šobrīd mēģinu apkopot risinājumus vis maz tam, kas man nāk prātā. Ne gluži. Situācija ir tāda, ka pasūtītājam jau ir lokāls risinājums, kas nav apmierinošs, un viņi tā kā veic funkcijas lai lokālo risinājumu (ne drupal, bet kaut kas custom) uzlabotu. Tas esot saistīts ar iekšējiem procesiem un biznesa vadību. Lokālo uz Drupal viņi negrib taisīt. Taču ir apsvēruši domu, ka externālo webu varētu taisīt. Vienīgi tikai nesaprotu kādēļ, ja nevēlas lietot paralēlu platformu. Tad jau būtu vieglāk tajā custom vidē pierakstīt extranetu. Bet tas ir tas mans viedoklis, uz kuru nosliecos, un sākumā to negribēju izteikt, lai nenovirzītos no tēmas. Ideja ir mēģināt saprast, vai tas ir iespējams, un vai tas ir jēdzīgi/racionāli kaut ko tādu darīt. Kādēļ Drupal? To nepateikšu, bet katrā ziņā domāju, ka tas ir saistīts ar pozitīvu informāciju par Drupal, salīdzinot ar custom risinājumu vājiem punktiem. Bet to izpildījumu pašlaik īsti neredzu.
varētu saturam ne-drupal vidē izveidot "ķeksīti", ka vēlas to redzamu "ārējā vidē". tad satura saite tiktu iestumta (push) ar sevisiem extranetā, bet tikai lokālais ID uz drupal nodes fīldu. Un tad kad skatītos to nodi no ārējās vides, tā varētu ielasīt saturu no iekšējās un ielikt to kešā. Tādējādi, būtu saturs tikai vienā vieta un lēna būtu tikai pirmā ielāde. Vēl varētu ka saglabājot saturu iekšējā vidē, caur servisiem tiek noresetots ārējās vidē konkrētās satura vienības kešs. t.i. aktualizēt saturu. vispār, "content staging" ir interesanta un attīstāma tēma.
Interesanta doma par ķeksi, taču tā kā tas ir intranet daļa, tad tā nebūtu mana uzdevuma puse. Un Content staging un caching, īsti vairāk laikam tomēr ir serveru štelle, ne tik daudz Drupal. Bet paldies par ideju. No sākuma vajadzētu tomēr tur ar X saprast, kas notiek, un pienākt pie konkrēta risinājuma par ko domāt. Pašreizējie ieteikumi man īsti nerada pārliecību/skaidrību, vai tas ir sakarīgs gājiens. Personīgi izvēlētos gan uzturēt katru platformu savā vidē. Vismaz vispārējā loģika un labā prakse to prasa. Un tad, ja nepieciešams, integrēt tās savstarpēji. Savukārt centralizēts menedžmenta risinājums - tā ir pavisam cita štelle, kur īsti nesaredzu saprātīgumu. (ja nu vienīgi ir vēlme stipri par to samaksāt :) )