Gratis, Delphi 10.1 Berlin Starter Edition

[[Delphius]]

Empezado por Casimiro Notevi

Se supone que si instalas zeos, funcinará como se espera.
En cuanto al BDE, es algo antiguo, obsoleto, abandonado, viejo, caduco, inservible... dejé de usarlo en 1998.

Zeos es una cosa y Data-ware es otra Casimiro. Creo que la edad te está afectando
A lo que apunta es que no viene con el DBGrid, DBEdit, etc. No se si es así efectivamente, pero cabe la posibilidad que así sea.

Yo aún no he instalado la Starter, y aún me lo replanteo.
Aplaudo que han aprendido de la experiencia de los Turbo y no cerraron la posibilidad de instalar componentes. Es un paso más adelante. Y deja abierta la posibilidad a que con componentes de terceros uno aún usando la Starter pueda ganar algo más.

Es justo esto lo que me motiva a que pruebe con Starter. Perdí una oportunidad maravillosa allá en el 2006, cuando la economía y las desmedidas del gobierno multiplicaron los precios... El precio del dolar, o en su equivalente en moneda nacional, era (y aún sigue siendo) una maldición. Para que se hagan una idea, pasamos de una relación 3:1 a una de 10:1. Es decir, comprar una licencia me salía 10 veces más. Hoy está a 16:1 pero al menos ya se ha sacado el cepo, podemos comprar dólores al fin con el cambio de gobierno... la cosa es tener ahorrado lo suficiente y pues no... no lo tengo.
Pero como dijo alguien antes (creo que fue retamar) ¡Si le vas a estar poniendo Zeos a Starter para tal caso mejor te vas con Lazarus! Yo también lo he pensado así...
Me debato entre el si y el no. Quizá gane el Si. Tampoco es que pierda algo.

Aunque confieso que me parece bien acertada la crítica de brakaman. Es un error haber no haber dejado lo mínimo de conexión... para mi lo mínimo es ADO. A mi ver esto fue un error... No te digo que dejen FireDAC... ADO en Starter hubiera sido un acierto y atractivo para los iniciantes.
Y también tengo mis críticas a que no se brinde compilación para 64bits. Alguien que tenga equipo (y /o sus clientes) con esa arquitectura (y dicho sea de paso, la enorme mayoría de los equipos hoy en día lo son) debe tener abierta esa posibilidad. Más sabiendo que ya hay un impulso tanto de parte por la gente de Linux, Microsoft y Apple a que se deje de lado ya 32bits. Es más, Ubuntu por caso para 2018 será exclusivamente 64bits.
Era una oportunidad única para Starter para ir acostumbrando a los que se inician y también para acercar más a la migración definitiva hacia 64bits.

En lo que me parece acertado es la limitación de los u$s 1000. No veo mal ese tema. Si tu como empresa chica, desarrollador independiente tienes ese margen de ganancia ANUAL signifca que tienes la suficiente solvencia económica como para pagar una Professional.
Si lo comparo en su equivalente a mi moneda, con la tasa actual de 16:1 es apenas $1000 pesos más que lo que costó comprar mi notebook. Aunque claro, llegar a ahorrar para comprarmela (y que es una usada) me tomó casi un año.

Saludos,

[Casimiro Notevi]

Empezado por Delphius

Zeos es una cosa y Data-ware es otra Casimiro. Creo que la edad te está afectando
A lo que apunta es que no viene con el DBGrid, DBEdit, etc. No se si es así efectivamente, pero cabe la posibilidad que así sea.

Cierto, la edad me está afectando mucho, por suerte, cada vez veo las cosas con más claridad.
No veo ningún problema con los componentes dataware, siempre he usado el dbgrid de las RX, lo demás me da igual.

[[Delphius]]

Empezado por Casimiro Notevi

Cierto, la edad me está afectando mucho, por suerte, cada vez veo las cosas con más claridad.
No veo ningún problema con los componentes dataware, siempre he usado el dbgrid de las RX, lo demás me da igual.

A mi me daría igual que tenga o no...
Me acostumbre a no depender de data-ware en D6, y cuando me fui por Lazarus aplico la misma regla. No los uso (salvo para hacer mis pruebas básicas).

El tema de los componentes de terceros si merece cierta atención... mientras los componentes o suites que deseemo instalar no dependan, directa e indirectamente, de dbExpress la cosa puede funcionar.
Zeos al no depender funciona.

Saludos,

[[AgustinOrtu]]

Iba a contentar lo mismo. No uso controles data aware. Para mi son como el bde. Los data aware te llevan a código espagueti. Desde que dejé de usarlos y me tome el tiempo de escribir el código que muestra los datos no sólo que queda todo mucho mas limpio y fácil de mantener. El resultado para el usuario hasta es mejor en términos de experiencia de usuario, tanto en lo lindo como en lo funcional.

Por ejemplo editar datos en un DbGrid me parece una aberracion. En ninguna aplicación moderna se ve algo como eso. Lo ideal me parece seleccionar un elemento del grid y luego llamar/mostrar un form o frame de edición.

En un form o frame tenés mucha más libertad a la hora de interceptar teclas, podés usar controles que permitan buscar, validar o presentar datos de una manera más limpia, fácil y clara. El DBGrid de Delphi (o de cualquier biblioteca de componentes en cualquier lenguaje) es el triste ejemplo de una clase que intenta hacer más de una cosa a la vez, y todo lo hace mediocremente

Por otro lado, habría que ver si en los componentes jedi hay un reemplazo. Admito que nunca los he usado

[[Delphius]]

Empezado por AgustinOrtu

Iba a contentar lo mismo. No uso controles data aware. Para mi son como el bde. Los data aware te llevan a código espagueti. Desde que dejé de usarlos y me tome el tiempo de escribir el código que muestra los datos no sólo que queda todo mucho mas limpio y fácil de mantener. El resultado para el usuario hasta es mejor en términos de experiencia de usuario, tanto en lo lindo como en lo funcional.

Por ejemplo editar datos en un DbGrid me parece una aberracion. En ninguna aplicación moderna se ve algo como eso. Lo ideal me parece seleccionar un elemento del grid y luego llamar/mostrar un form o frame de edición.

En un form o frame tenés mucha más libertad a la hora de interceptar teclas, podés usar controles que permitan buscar, validar o presentar datos de una manera más limpia, fácil y clara. El DBGrid de Delphi (o de cualquier biblioteca de componentes en cualquier lenguaje) es el triste ejemplo de una clase que intenta hacer más de una cosa a la vez, y todo lo hace mediocremente

Por otro lado, habría que ver si en los componentes jedi hay un reemplazo. Admito que nunca los he usado

Yo no tengo una visión tan radical como para decir que data-ware es de lo peor... Tampoco me atrevería a decir que el DBGrid por defecto que trae Delphi (al menos el de D6) sea mediocre.
La gracia y una de las ventajas que tiene Delphi es justamente el RAD. Y que con pocos pasos ya tienes un ABM funcional. Descartarlo por descartarlo no me parece bueno.
Lo que me parece espectacular es que los Ingenieros detrás de Delphi han tenido una muy buena visión de como hacer las cosas y no te condicionan ni te imponen a que para llegar a la bases de datos obligadamente pases por el data-ware. El que sea opcional, y uno considere o no usarlos. No se si otros lenguajes permitirán estas libertades.
Si hay algo que siempre han hecho bien el equipo es ofrecer un equilibrio en su VCL.

Mi motivo por el cual renuncio al data-ware es más bien centrado a mi visión con tendencia al OO-puro o purismo-OO. En ciertos puntos, si uno se pone a analizarlo se encuentra en el dilema de si usar o no data-ware. Rolphy Reyes y yo en DA hemos intercambiado nuestras experiencias y coincidimos en algunos temas. Ambos nos seguimos cuestionando hasta donde nos puede llegar a facilitar el uso de data-ware y en que punto nos perjudica cuando tenemos presente una capa de de Modelo de Negocio, junto a una Capa de Presentación y otra Capa de Aplicación... y ni que decir, si hemos llegado a pensar en elaborar un Framework de Persistencia.
Y creo que acá en CD también se ha debatido este tópico.

Es una visión personal. Hay gente a la que el manejo de data-ware les es esencial y a otros que no. No creo que se llegue a una respuesta definitiva que nos diga que deba ganar una cosa por sobre la otra. Después de todo, sea cual fuese el camino que elijas tendrás tus pros y contras. Mientras uno esté al tanto de ambos y encuentre "equilibrio" en sus propios diseños las cosas pueden ser llevadas con normalidad y debido control.

Saludos,

[Caminante]

Empezado por Delphius

La gracia y una de las ventajas que tiene Delphi es justamente el RAD. Y que con pocos pasos ya tienes un ABM funcional. Descartarlo por descartarlo no me parece bueno.
Lo que me parece espectacular es que los Ingenieros detrás de Delphi han tenido una muy buena visión de como hacer las cosas y no te condicionan ni te imponen a que para llegar a la bases de datos obligadamente pases por el data-ware. El que sea opcional, y uno considere o no usarlos. No se si otros lenguajes permitirán estas libertades.
Si hay algo que siempre han hecho bien el equipo es ofrecer un equilibrio en su VCL.
Mi motivo por el cual renuncio al data-ware es más bien centrado a mi visión con tendencia al OO-puro o purismo-OO. En ciertos puntos, si uno se pone a analizarlo se encuentra en el dilema de si usar o no data-ware. Rolphy Reyes y yo en DA hemos intercambiado nuestras experiencias y coincidimos en algunos temas. Ambos nos seguimos cuestionando hasta donde nos puede llegar a facilitar el uso de data-ware y en que punto nos perjudica cuando tenemos presente una capa de de Modelo de Negocio, junto a una Capa de Presentación y otra Capa de Aplicación... y ni que decir, si hemos llegado a pensar en elaborar un Framework de Persistencia.
Y creo que acá en CD también se ha debatido este tópico.

Es una visión personal. Hay gente a la que el manejo de data-ware les es esencial y a otros que no. No creo que se llegue a una respuesta definitiva que nos diga que deba ganar una cosa por sobre la otra. Después de todo, sea cual fuese el camino que elijas tendrás tus pros y contras. Mientras uno esté al tanto de ambos y encuentre "equilibrio" en sus propios diseños las cosas pueden ser llevadas con normalidad y debido control.

Saludos,

Hola a todos

Soy de la misma opinion el usar o no controles dataware no tiene que ser mejor o peor para todos los casos. Yo tengo un sistema funcionando con dataware en una de sus ventanas muestro en un dbgrid la lista de prestamos de mercaderia hechos a un cliente y hay un campo que es el unico editable que es la fecha de devolucion. En este caso se me hace un poco tonto crear un cuadro de dialogo para modificar una sola columna (Si fueran mas se justificaria). Me basto insertar un TDateedit (JVCL) en la columna del grid y listo.

Lo que quiero decir es que cada situacion se puede resolver de una u otra forma.

Ahora que he cambiado a codetyphon estoy cambiando a un modelo de objetos pero unicamente porque no encuentro un componente que pueda igualar al clientdataset.


Saludos

[[AgustinOrtu]]

Casi que estamos de acuerdo; yo tambien prefiero el modelo purista de objetos porque se permite enchufar a cualquier cosa y no depende de los data-aware. Como migras el mismo codigo a firemonkey para multi plataforma? no podes, no tenes data-aware ahi

Por otra parte, la Starter si tiene los controles data-aware, y tambien tiene ClientDataSet:



Y tambien tiene LiveBindings aunque sin el "experto" o plugin del IDE que hace todo mas facil, hay que crear los Binding a mano usando un componente TBindingList y su menu contextual (es como si se crearan Actions de un TActionList)

Este ejemplo es en firemonkey



Tambien estan los componentes de Tethering e Internet (los nuevos TNetHttp de XE8 creo), los sensores (LocationSensor, MotionSensor, OrientationSensor), Bluetooth y BluetoothLE. Tambien vienen los VCL Styles (incluidos los de Windows10)

En fin,m que no esta tan mal!