Lift-JRuby Integration Bridges the Gap Between Ruby and Scala
Questo articolo presenta una iniziativa mirata a rendere fruibile il
web-framework Lift, scritto in Scala, attraverso una API Ruby, con
JRuby.
Un commento la considera una mossa ardita ma accolta con curiosit
sugli sviluppi futuri…
Voi che dite?
Lift-JRuby Integration Bridges the Gap Between Ruby and Scala
Questo articolo presenta una iniziativa mirata a rendere fruibile il
web-framework Lift, scritto in Scala, attraverso una API Ruby, con
JRuby.
Un commento la considera una mossa ardita ma accolta con curiosit
sugli sviluppi futuri…
Voi che dite?
che non ha senso, se i motivi che sembrano aver spinto David P. a
farlo sono “perch ruby ha pi successo nell’enterprise”.
Se uno riuscito a vendere ruby alla propria (o altrui)
organizzazione, e fosse in grado di duplicare con jruby & lift,
sinceramente non penso fallirebbe nel fare lo stesso per lift & scala.
(per non dire che il problema pi grosso di lift fino ad ora stata
la documentazione imvho)
Ma comunque una possibilit in pi, quindi sempre interessante
Lift-JRuby Integration Bridges the Gap Between Ruby and Scala
Questo articolo presenta una iniziativa mirata a rendere fruibile il
web-framework Lift, scritto in Scala, attraverso una API Ruby, con
JRuby.
Un commento la considera una mossa ardita ma accolta con curiosit
sugli sviluppi futuri…
Voi che dite?
Dario
Dico che è meglio poter fare una cosa in più che una in meno, anche se
quella in più si rivelasse quasi sempre inutile
In parte offtopic:
Dopo aver guardato lift mi chiedo però che senso abbia la sua decisione
di design di eliminare i controller. Di fatto gli snippet di lift nel
mondo Rails sono metodi di modelli o helper. Il controller Rails
identifica la risorsa principale a cui fa riferimento l’url, aiuta il
routing e permette di creare con facilità applicazioni restful. Con gli
snippets di lift si finiranno per creare di nuovo applicazioni con
url-spaghetti, oltre a sparpagliare i punti d’accesso della business
logic in una miriade di view con un impatto negativo sulla
manutenibilità. Anche in Rails abbiamo la business logic sparsa nei
modelli, ma almeno si riesce a capire facilmente come metterla insieme
leggendo un solo file controller.
A fronte di questi passi indietro (il view-first era il paradigma ASP
degli anni '90), secondo voi quali sono le ragioni per
cui sta piacendo lift? La nostalgia?
modelli, ma almeno si riesce a capire facilmente come metterla insieme
leggendo un solo file controller.
A fronte di questi passi indietro (il view-first era il paradigma ASP
degli anni '90), secondo voi quali sono le ragioni per
cui sta piacendo lift? La nostalgia?
I miei 2 fiorini:
Credo che l’idea sia che gli snippet rappresentino dei micro
controller perch nel mondo-visto-da-lift un’applicazione non una
serie di pagine ma una serie di elementi stateful che possono stare
anche nella stessa pagina. Il vantaggio che uno snippet/mini-mvc
(chat, menu) pu essere usato in diversi posti (e renderizzato in
parallelo) mantenendo il suo stato indipendentemente da quel ha
intorno.
In effetti, quando si iniziano a fare dieci metodi che generano
frammenti da mettere in una pagina via ajax la restfullness si gi
persa in parte, credo, ma non sono abbastanza bravo da giudicare gli
effetti dell’approccio alla lift.
Sulle ragioni per il suo successo: sicuro piaccia cos tanto?
Direi comunque che sia principalmente dovuto alla situazione nel mondo
Scala: chi usa e vuole usare Scala non ha molte altre alternative
native, e soprattutto non ne aveva quando Lift stato pubblicato
inizialmente, forse una situazione analoga a quando in python Zope
aveva il maggior mindshare anche se a molti non piaceva.
Secondo me la cosa pi bella di Lift che supporta molto bene i
meccanismi di long polling/comet nel suo core, mentre in altri
ambienti sono abbastanza appiccicati sopra (e per quelli gli snippet
sono ideali).
