progetto web forum lazaruspascal.it

[aesis]

Anche noi pensiamo che per arrivare a scrivere una RIA vera e propria che comunque sarà influenzata pesantemente da quello che attualmente si ha a disposizione (non è pensabile rimettersi a scrivere i componenti tipo button,edit..etc quando abbiamo +10 top library che già lo fanno...) bisogna creare un sistema semplice e snello per scrivere una pagina html con tag PASCAL interpretabili. Questo sviluppo poi dovrà essere completato con plugin sempre più user-friendly, GUI e quant'altro...ma adesso il problema è la base..il core.

Marco e Samuele.

[nomorelogic]

ok, ok... non provoco più

ho cambiato idea: provoco ancora!
http://wiki.lazarus.freepascal.org/DELPHI_FORM_TO_HTML_CONVERTER

[xinyiman]

Voglio fare una domanda...ipotizziamo che abbiamo fatto la beta, una delle cose più probabili è la necessità di connettersi ad un database, ipotizziamo anche che non produciamo una cgi, con cosa ci colleghiamo?! Riscriviamo le zeos in modo tale che rilascino codice php?! Per collegarsi ai vari db?!

Secondo me è importante anche snocciolare il dopo beta prima di aver fretta di partire...

[Stilgar]

xinyiman, la connettività verso un db è cruciale perchè non rimanga una cosa da nerds.
Al giorno d'oggi cosa ti aspetti da un FW Web?
Connettività verso DB e Ajax a manetta per non ricaricare tutto ad ogni pisciata di cane.
Io rimango della mia idea.
Si fanno delle librerie di tag base. (Ricordatevi che abbiamo già il lettore di "template" gratis, senza dover reinventarsi parser e madonne varie). Anche se a normore sta antipatico, il documento XML che ne esce come template è già pronto all'uso.
Basta scrivere solo la gestione dei tag specifici.
Dare supporto ajax nelle chiamate.
Poi volete fare altre cose? Si possono aggiungere dopo, non diventando ebeti mettendo tutto e subito.
1) Tenete conto che si tratterebbe di mettere assieme tutte cose che ci sono già. (per gli imprenditori che bazzicano questo forum = bassi costi di startup).
2) JQuery ha una botta di plugin già pronti per fare moltissime cose. Quello che manca (se manca) si può fare. JQuery UI ha abbastanza widget per iniziare. E JQuery è una sorta di "garanzia" (Good References?)
3) Le tag libraries standard creerebbero dei paletti dove l'utente non ha molti spazi per dare la "colpa" del "non va na madonna" (avrei usato un'atra espressione, ma il forum è pubblico).
4) La sintassi "pascaliana" è un plus ma anche un handicap. Teniamo conto che la maggior parte degli sviluppatori web conoscono : JSP, ASP, APS.net, PHP.
Se diamo una cosa a loro familiare in mano, magari un attimo più veloce e performante, magari la cosa è più digeribile ai "neofiti".
Butto lì alcuni concetti.
Lavoro "tosto" da fare.
1) Capire quali tag servono.
2) Creare una priorità alle varie librerie.
3) Creare delle utilities che vadano bene oggi e dopodomani, senza doverle rimaneggiare ad ogni rilascio.
4) Prevedere l'uso di SVG appena IE inizia a supportarlo (formato grafico w3c).
Continuo?

Stilgar

[Stilgar]

A proposito, poi ci sarà da scrivere un IDE a parte per lo svilippo.
Magari è quello che potrebbe diventare un attimino fonte di dindini

[xinyiman]

Stilgar concordo con te, approfondiamo un attimo il discorso di scrivere tag?! Che idea hai in mente?!

Snoccioliamo i dettagli?!

[Stilgar]

Oddio, quello lo vedo come un problema secondario, in questa fase.
Servono tag per la gestione di cicli, DML (e DDL? Se usiamo Zeus come connettore, non ci sono problemi di sorta).
L'uso di queste cose prevede un rtti molto pesante e preciso.

Adesso, il mio "problema" non è tanto la parte "web" pura, ma la parte "server".
Mi spiego, meglio.
Nel mondo Java esistono 2 entità che coesistono nei JSP container.
JSP (appunto) e Servlet.
Alla fine sono la spessa identica cosa, ma le prepari con due approci radicalmente diversi.
Le JSP le scrivi in XML (in soldoni) e le servlet le scrivi in java puro.
Il problema che abbiamo è il deploy. Quello è uno scoglio duretto da digerire.
Questo per quale motivo?
Le WebApplication di java usano le servlet (al giorno d'oggi) per fare il lavoro di back end e le jsp quello di front end.
La forzatura che proponevo qualche post fa ricalca questa filosofia.
Gli action controller, altro non sono che servlet specializzate.
Quello che sto cercando di immaginare è il meccanismo che permetta di deployare le "applicazioni" a caldo, in un apache, tanto per iniziare.
Ci sarebbe il modulo per poter interagire con Apache da sfruttare, ma poi?
L'unica strada che al momento vedo praticabile fin da subito, con basso costo di partenza è l'uso di DLL caricate e scaricate on demand.
Quindi mettere in piedi un meccanismo tipo loader applicativo.
Ma non l'ho ancora sognato Quindi è ancora abbastanza fumoso al momento

Stilgar

[Stilgar]

insomma, se siamo d'accordo su cosa deve scrivere l'utente (xml) il problema a questo punto è il motore (core come dicevano sopra).
Deve essere snello è robusto.

[Stilgar]

xinyiman, per ogni tag che metti in pagina, se non è un tag html, fai partire una classe.
Tutte devono implementare un'intergaccia (ITag per comodità e poca fantasia).
A queste devi passare uno stream (in modo che la generazione della pagina sia pezzo per pezzo tutta in memoria).
Esitono 3 macro categorie di tag.
1) One Shot. (quelle che si aprono e si chiudono senza sotto tag)
2) Quelle con "body". (quelle che possono avere sotto tag).
3) Quelle con ricircolo (vedi una tabella, quella per ogni riga ricorcola, idem per le righe, ricircola le colonne).

Poi basta farsi una letta delle specifiche jsp per avere l'ossatura di quello che c'è da fare
Nulla di incasinato dal punto di vista del design.
Stilgar

[nomorelogic]

Gli action controller, altro non sono che servlet specializzate.
Quello che sto cercando di immaginare è il meccanismo che permetta di deployare le "applicazioni" a caldo, in un apache, tanto per iniziare.
Ci sarebbe il modulo per poter interagire con Apache da sfruttare, ma poi?
L'unica strada che al momento vedo praticabile fin da subito, con basso costo di partenza è l'uso di DLL caricate e scaricate on demand.
Quindi mettere in piedi un meccanismo tipo loader applicativo.
Ma non l'ho ancora sognato Quindi è ancora abbastanza fumoso al momento

quando posto sono solo opinioni e/o idee, spero di non aver scritto in tono autoritario perchè, nel caso, chiarisco subito che non avevo dictact in testa

evitare file esterni, che siano xml o altro, era un modo per semplificare il lavoro iniziale abbassando il target della beta
l'idea era quella di mettere questi tag embedded nell'html, costruire un meccanismo che gira e poi riflettere di nuovo
del resto ci sono gli stress test da fare, paragonare i tempi con altri strumenti ed molto altro ancora

però non ho capito la strada che hai in mente: nessun modulo ma varie dll?

[Stilgar]

In pratica "l'applicazione" è una DLL. Questa ha dentro sia gli xml, sia il codice.
Diciamo che il modulo di connessione con il web server sarebbe una cosa "scritta" una volta e usate per tutte.
Diciamo che sono le basi per un vero application server.
Il modulo caricherebbe e scaricherebbe l'applicazione in caso di aggiornamento

Stilgar

[nomorelogic]

per fare questo non è complicato
il modulo apache c'è e si occupa di caricare dinamicamente le dll di turno.
magari anche con una interfaccia web per la manutenzione dei plugin.

tornando ai plugin... la cosa mi piace perchè a cose funzionanti uno può anche implementare "server pages" differenti e/o farsi il suo application server e la cosa non è male

forse l'interprete pascal dovrebbe essere un plugin del modulo apache così come lo dovrebbe essere la parte "server pages" (ovviamente i 2 plugin devono comunicare).
in questo modo il modulo dovrebbe caricare/scariacre le dll/plugin e smistarci le chiamate.

[aesis]

Allora Ragazzi,
secondo noi è necessario fare un po di chiarezza leggo i post di Stilgar, nomore sono molto interessanti ma mi rendo conto anche molto teorici (forse xinyiman sul primo post quando diceva allora che si fa...in pratica aveva un po di ragione...    )
Proviamo a schematizzare il tutto..che ne dite? Rendere le idee tecniche/teoriche in modo comprensibile a tutti..siamo pochi che scriviamo ma sono sicuro che gli altri del forum leggono e magari si chiedono "ma questi de che parlano in pratica??"....Scusate magari sbagliamo però a volte anche noi facciamo fatica a capire le varie sfumature di quello che abbiamo intensione di implementare. Accettiamo critiche! ahahahah
Marco e Samuele.

[nomorelogic]

avete dannatamente ragione

[Stilgar]

http://www.tutorialspoint.com/jsp/index.htm

Diciamo che questo giustamente è orentato a Java.
Basta pensare che i pezzi "java" diventino ObjectPascal


Stilgar