Discussions

News: XGQL 2.0, an alternative to the complexity of frameworks?

  1. XGQL offers an alternative to the frameworks applying the classic MVC model. It lowers the vertical complexity of complex architectures and tries to contain the horizontal complexity by offering a readable and easy to use syntax. Let's get back to the main reasons why we use frameworks: The initial purpose is to handle tasks at different levels (db connections, Object management, handling protocols etc.). The underlying idea is to split the problem in pieces to make it easier to solve at each level. In the end, you just want to deal with the real logic of your application. It is still true today but the problem is that the growing number of frameworks available has introduced a new level of complexity in the applications. This level is: How do the different layers of the applications communicate and how to organize them? For large applications it is reasonable to invest in people who know how to handle this complexity at the architecture level. For smaller applications, it's not worth it. Why spend more time in creating the architectural structure of your application than in the business logic itself? There is a wide variety of applications that have to be developed within a short period of time for specific purposes (internal application or very specific customs development). XGQL is designed for this kind of development because it is quick and easy. It avoids wasting time on elaborating architectures that will take a long time to implement and difficult to maintain because few people will have the knowledge to do it. Technically speaking:
    • It requires a JRE to run the XGQL parser (written in Java).
    • It can run in API or Web server mode. This means that you can use XGQL scripts in your Java applications and use the result of the processing or directly in a Web application just like JSP Tag libs. XGQL has its own syntax, libraries and Extension mechanism. XGQL can be used instead of any other Java/PHP framework to build middle size applications because it reduces the complexity of framework architecture.
    • The code is readable, simple and easy to maintain
    • In a single XGQL script, you can use connections to several DB, XML or SOAP flows from other remote applications
    • You can use local files, FTP, or HTTP to get your data and work on it
    • You have the ability to use SQL and Xquery/XPath at the same time and use the results of these queries to format your result.
    To sum up: One XGQL Script = XGQL syntax + multiple DB connections + multiple Dataflows (XML, text, SOAP) + Ability to perform queries both in SQL and Xquery + Ability to format the result The new version of XGQL is now available for download. Visit the project home page at: http://xgql.sourceforge.net for further details, documentation and tutorial. Message was edited by: joeo at enigmastation dot com (clarified grammar)
  2. is it something like linQ[ Go to top ]

    is it?!!!
  3. Re: is it something like linQ[ Go to top ]

    You can compare this to LinQ in the way that you can mix relational Data with XML to manipulate data, but there are several differences: - This is a scripting language - Java based and not .Net - There is no code generation (No db mapping, this is not the purpose) - The possibility to connect to several datasource simultaneously (MySQL, SQL Server etc.) as long as you have the JDBC drivers - You can perform 'Create', 'delete' and 'update' - You can use inner XQuery/Xpath expressions - As XGQL generates XML, the final representation of data is by nature XML, as a consequence, It might be easier to generate Xhtml for instance because there is no formatting operation to perform. I think their goal is slightly different. - LinQ focuses on offering new query facilities to programming languages - XGQL aims to externalize the data manipulation.
  4. not another web framework LOL.... but it does look interesting,being that is very simple MVC for small applications.
  5. Not just another web framework[ Go to top ]

    Well, it can be used as a web framework, but initially it was designed to express business rules using Java API. The original idea was to externalize the business rules in scripts so that when you want to modify them, you don't have to deliver a full release of your application, you just deliver a new version of the script expressing the rule. In the end it appears that XGQL could be used as a Web framework as well. So, I think only time can tell whether it will find its place LOL ...
  6. From the user manual: "This tag allows to process SQL for queries, update, delete or modify." Didn't we spend years creating and discarding countless other frameworks to get rid of this kind of thing?
  7. From the user manual:

    "This tag allows to process SQL for queries, update, delete or modify."

    Didn't we spend years creating and discarding countless other frameworks to get rid of this kind of thing?
    Quite true. But on a slightly different note - and detached from this particular announcement - it may well be that this was bad idea. A lot of people rant and chant about "domain specific languages" nowadays, and hey, SQL turns out to be *the* domain specific language when accessing relational data :-). Also databases that were not specifically (re-) engineered for "framework" use tend to evade whatever fancy ORM technique you are using. Let me not get started about the thousands of data models that may only be accessed using stored procedures only.
  8. From the user manual:

    "This tag allows to process SQL for queries, update, delete or modify."

    Didn't we spend years creating and discarding countless other frameworks to get rid of this kind of thing?


    Quite true. But on a slightly different note - and detached from this particular announcement - it may well be that this was bad idea.
    In my personal experience, moving away from direct use of SQL has been one of the best decisions. Even the most substantial database-linked applications I write are trivially portable across different vendor's products, while remaining efficient.
    A lot of people rant and chant about "domain specific languages" nowadays, and hey, SQL turns out to be *the* domain specific language when accessing relational data :-).
    For simple purposes, sure. But for anything substantial you almost inevitably deal with vendor-specific SQL. There is no one thing called 'SQL' that can be used universally and portably for anything substantial. I have been dealing with this issue for decades now. My domain-specific language for accessing data of all kinds is JDOQL (and probably, in future, JPAQL).
    Also databases that were not specifically (re-) engineered for "framework" use tend to evade whatever fancy ORM technique you are using. Let me not get started about the thousands of data models that may only be accessed using stored procedures only.
    One of the great things about modern ORMs (especially JDO 2.0) is their improved ability to deal with existing relational data models and stored procedures. They aren't perfect, but are far better than using SQL directly. I believe that embedding substantial amounts of SQL in any code is a major backward step. I know personally of many projects that are stuck on a particular vendor's database, and hence on a particular platform because of this approach. I think that current and future Java tools and projects like this should at the very least include the option to use JPAQL instead of SQL. There is a standard for portable querying in Java. Let's use it.
  9. Well said Steve! I agree wholeheartedly. SQL is a language for database access. It not an OO language and so it can't encapsulate behaviour - only data. Some people seemed to have missed the whole point of the last 20 years of object oriented software development: encapsulate both data and behaviour, throw in some judicious use of inheritance and then you can start building quality software by creating entities that model their real world counterparts by allowing you to specify both their data AND behaviour. By continuing in their software development persuits with an obsession of 'coding' at the SQL level they limit themselves to a data oriented view of the world, ignoring the benefits of creating software that models both data and behaviour. This fundamental OO approach is taught in computing 1.0.1 at most good universities these days. To address the 'fear of complexity' some people have with ORMs which allow software development by OO modeling and relegate SQL to the low level database access language that it is I have to say that I've been using JDO (JPOX) now for 14 months and my domain models are all simple POJOs. There's no complexity in POJOs. They aren't hard. JPOX just persists my domain model objects for me - it's a no brainer. They don't call it 'transparent persistence' without good reason. So yes it's a framework but that whole 'transparent' thing makes it real simple to use. Other frameworks I use that are also pretty cool: Wicket - for tradition HTML page generation - very cool OO component based UI framework - simple to use and eats struts/jsp for breakfast. Echo2 - for highly interactive websites - it feels more like you're coding a Swing app than a web app - and it's easy to learn. Everytime I hear about some new 'SQL' oriented, 'easy to use' 'framework-less' solution it sounds like someone who has just discovered the world's best 8088 macro assembler - who cares? Assembler is a language for low level CPU manipulation (load from/to register, push value on stack etc.,) and I choose to develop at a much higher level than that (sure I might need to code in assembler to get that extra speed sometimes - NOT!). In a similar vein SQL is a language for low level data manipulation (tables/columns/rows/result sets) and I choose to write at a higher level than that too.
  10. A lot of people rant and chant about "domain specific languages" nowadays, and hey, SQL turns out to be *the* domain specific language when accessing relational data :-)
    These people always ranting and chanting about everything either 1. have spent all their computing life doing that and they simply need to find something new to rant and chant about 2. are inexperienced developers with a narrow view on the whole field of application development and hence tend to rant and chant about anything that's cool enuff for their current needs I'm being very cynical here, but these are my lessons learned.
  11. MVC framework?![ Go to top ]

    Could you explain: how Model, View and Controller are separated? It looks like this is not a framework but few jsp tags. And I hope that nobody wants to write scripts in jsp pages again.
  12. Re: MVC framework?![ Go to top ]

    I have already used XGQL in many projects and the question is not “who want to write scripts in jsp pages again?” but it’s “why XGQL can help me?” XGQL and JSP are not the same things and haven’t the same goal. XGQL can be used as a web framework, but its first goal is to generate XML (XHTML by extension). XGQL is a API which generate XML from differents sources (database, http, ftp or filesystem) with differents tools (XPath, Xquery and SQL). The script syntax are very easy to learn and to understand (30~40 minutes with the documentation). How Model, View and Controller are separated? Simple! Don’t used XGQL for the View. XLST is a best choice (for me). XGQL is a simple way to generate and modify data. This is not a complexe framework for complexe project than struts or JSF. XGQL is easily to deploy, more adapted for small project or a API integrated in an another framework.
  13. For smaller applications, it's not worth it. Why spend more time in creating the architectural structure of your application than in the business logic itself? There is a wide variety of applications that have to be developed within a short period of time for specific purposes (internal application or very specific customs development).
    I don't think this is exactly re-inventing the wheel, but I can't really see the point when there are already solutions that hide the supposed complexity of frameworks, but maintain their advantages; Seam and Grails for example.
  14. not sure why spring or struts cant be used for mid size applications also. why are you saying they bring complexity ? learning a whole new language of yours is not complex ? whats your 5 year plan from today - where is your language heading ? is there any chance that 2 years from now it will be hard to find you and your language , forget about ANY KIND OF SUPPORT . why waste your time reinventing the wheel ? yes it is reinventing - may be unnecessary reinventing. and dont start silly lecture on how its about bringing new choice , competition blah blah blah ... you will soon be one of those half baked useless ideas found on sourceforge.net. yeah i m blunt.. its required to put some sense in most of these ideal heads. sure go ahead reply to this and waste more time.... i wont waste any.