I'm new to delphi and I'm looking up on ways to learn more about delphi underlying technology plus make something useful here in my job in the process, also if anyone has any tip or see anyway i can improve my idea please fell free to speak your mind...
i want to do make some kind of Scaffolding for dfms, the ideia is the following: i want to generate based on a firebird database table - with well defined domains - the bulk of the Form .
I think the idea is too simple or i'm not seeing the big picture that makes it difficult, i'm trying not to reinvent the well, i've looked up on google but without good results, so if anyone could giveme a direction here i would be most grateful.
UPDATE:
#Larry Lustig thanks, i didn't think about delphi frameworks - i'm going to look them up.
i know something about form objects/handling and database metadata, but i'm unfamiliar with serilizing delphi objects to the HD. Any tips on Serialization and delphi frameworks (opensource so i could take a look :) ) would be welcome!
Sounds like an interesting idea.
Instead of writing a DFM form manually on disk I would use the following approach:
Get the structure of your table by examining the meta data.
Create a TForm and add a control to it for each column you want to represent.
Use Delphi's built in serialization to save the form to disk.
I haven't done this myself, but there are a number of run-time design frameworks that work using this idea.
This would only make sense if you need to build a lot of forms at design time. You can't use the DFM's in your executable's. If you want to build the forms runtime, I suggest you go with Larry Lustig's answer.
We have taken this one step further... we don't build forms. We only write the classes, add some attributes and create the forms at runtime. Users can change this preset form layout during runtime and save their own layout. Data binding between the controls and the database is done with the excellent tiOPF framework. Maybe something you can consider to use as well.
Related
I have an existing application which is quite large, uses a SQL Server database and LINQ to SQL built in MVC. It does what it needs to do very well, but the CMS is sadly lacking (it's difficult, complicated to use and prone to errors).
I like the look of Composite C1 to migrate this application to so that my users can get a good CMS experience.
I don't really want to center my development around C1, so I've been looking at creating an MVC application:
http://docs.composite.net/Functions/MVC
I've created a sample controller, view and then returned some static data to the view and finally posted some data to the controller. All works as a "normal" MVC application would do.
Has anyone used this concept for a real world application? The idea is that if a user want's to display one of my controls on a page they just add the control via the Composite editor. I'll also add basic pages on installation.
It's a bit of a vague question, but I'm really looking for feedback on the following:
1) How "involved" do you need to be with Composite C1 stuff? I want to just create my controllers and other classes to do my work
2) How is the performance with this approach?
3) Is there many gotcha's that you've experienced?
I have built a larger application within/on top of a Composite C1 environment, so I can say its definitely possible and the compatibility with .NET application development is actually one of the main reasons why we chose Composite in the first place.
1) How "involved" do you need to be with Composite C1 stuff? I want to just create my controllers and other classes to do my work
You won't be able to completely ignore everything Composite related when developing a full fledged application however, simply because your controls/views/controllers will run on and be rendered by Composite C1. So necessarily some of the work is done at least in part by the C1 foundation you build on, e.g. Routing, Exception Handling or Rendering.
However you can usually work with or around those features without too much trouble. It may however take some understanding of how Composite works.
2) How is the performance with this approach?
So far I cannot say that Composite would slow down the application in any significant way. It may in fact support you in tasks like Output Caching.
3) Is there many gotcha's that you've experienced?
This is a very broad question, but you generally will always have to make sure you know whether something belongs in one of your controls or would be better fit into a Composite component (page, reusable html block). If you put things into the wrong place, the easiest things will become complicated (like creating a page link) due to information being not present in the current context. But as I said, you can solve this through clever design.
Another thing to look out for is that correct source versioning is a bit harder to set up in the first place with a Composite application, because you have to figure out what is content and what is application.
So far I have made good experiences with C1 and will be using it in the future. It may take a little more time to get into it in the first place compared to a vanilla ASP.NET application, but the work that is done for you regarding CMS parts is well worth it.
Note: This is a follow-up question for this previous question of mine.
Inspired by this blog post, I'm trying to construct a fluent way to test my EF4 Code-Only mappings. However, I'm stuck almost instantly...
To be able to implement this, I also need to implement the CheckProperty method, and I'm quite unsure on how to save the parameters in the PersistenceSpecification class, and how to use them in VerifyTheMappings.
Also, I'd like to write tests for this class, but I'm not at all sure on how to accomplish that. What do I test? And how?
Any help is appreciated.
Update: I've taken a look at the implementation in Fluent NHibernate's source code, and it seems like it would be quite easy to just take the source and adapt it to Entity Framework. However, I can't find anything about modifying and using parts of the source in the BSD licence. Would copy-pasting their code into my project, and changing whatever I want to suit my needs, be legal for non-commercial private or open source projects? Would it be for commercial projects?
I was going to suggest looking at how FluentNH does this, until I got to your update. Anyway, you're already investigating that approach.
As to the portion of your question regarding the BSD license, I'd say the relevant part of the license is this: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: [conditions follow].
From my reading of that line, you can modify (which would include the removal of any code not relevant to your use cases) the code however you wish, and redistribute it as long as you meet the author's conditions.
Since there are no qualifications on how you may use or redistribute the code or binaries, then you are free to do that however you wish, for any and all applications.
Here and here are descriptions of the license in layman's terms.
I'm always writing simple set of integration tests for each entity. Tests are persisting, selecting, updating and deleting entity. I thing there is no better and easier way to test your mapping and other features of the model (like cascade deletes).
Is "Replacing non-visual components with code" a proven optimization technique in Delphi 7. Mainly with respect to Database Access.
The Web site you cite talks about replacing a dialog-box component with code that would display the dialog box without the use of any component. The alternative is to write a couple of lines of code to set up and display a dialog box whenever you need one, and to skip the component altogether. It's not really an optimization in speed or size, though. It's not a speed optimization since your code would do exactly what a component would have done anyway, and it's not a size optimization because the space any one component occupies in a program is negligible.
Database components aren't so easily replaceable as dialog-box components. Nearly everything in Delphi is designed to use descendants of the standard database components. If you don't use the components, then you won't be using any of Delphi's database capabilities at all. You can use the database libraries' native APIs if you wish, but I think that would be foolish if your goal is really optimization and you haven't identified the components as the source of your program's non-optimal behavior. Consider how much time and effort it would take you to rewrite your program without the database components.
I don't see how a form-based dataset/query/table/etc., would be faster or slower than one created in code. However, I like to put them in code as it's easier to maintain. I've seen screens with SQL embedded in a component, and then it's overridden in the code. Then I have to stop and investigate to determine which SQL is actually in effect. Sometimes the SQL in the form is good, sometimes it's used for a while and then trumped by the code, sometimes it's never active and the SQL is trumped in the formcreate. So I have to determine whether this is by design, or just sloppy leftovers. Also, it's easy to miss SQL changes in code reviews if they're in the .DFM and not the .PAS. i.e. I don't always look at the .DFM because I'm not interested in whether a label caption changed or a button moved.
So while it's nice for prototyping, when it comes to production code, you're better off having all of your database logic (SQL, table and field definitions) in the .pas file.
Update: I have finally given CnPack a try. Among the dozens of goodies, is a brilliant tool called "convert selected components to code". Form Design Wizard | More... | Convert Selected Components To Code. It does it all for you.
This is not a matter of being a component or not a component. If it comes to database access then BDE is extremely slow so changing it for sth else is a good move.
By the way - optimization is not about 'proven techniques' - it's about identifying a problem and solving it. If the problem happens to be slow db access then this is what you have to change.
Generally no. There is no additional overhead in using a non-visual component. It is created very quickly and works at runtime exactly at the same speed as one "created in code".
After years of coding Delphi programs as untestable code in forms and datamodules, including global variables, and the only classes are the forms themselves, containing all the code I need for the form UI itself.
How would I convert the code to a set of classes that do the actual work? would I need to stop using the datasources/datasets and do everything in classes? do I need an ORM?
There's usually zero need for reuse of the code in the forms, so does it make sense to convert the logic to classes?
If I encounter a form (or other class) with too much responsibility, I usualy follow the pattern below:
Define a new class for the logic.
Create a member variable of the new class in the form.
Create the class in the onCreate and free it in the onDestroy of the form.
Move a single piece of logic (for example a variable) to the new class.
Move or create all methods to the new class.
Compile and test.
Continue until all logic is put in the new class.
Try to decouple the logic class from the form class. (You can even work with interfaces if you like).
There are situations where a single class is not enough, so it is no problem to create more classes. And these classes can have other classes to.
With these steps, you can tackle most of these problems.
To start with I can highly recommend reading the book Refactoring by Martin Fowler.
This will give you a real understanding about how best to sensibly approach introducing changes to the existing (non OO) code to improve maintainability.
I would not look at an ORM until you have a clear understanding about what benefits (if any) one would bring to your application.
I have encoured problem like this with one application, I start doing the following:
Define main classes for most general logic in the code.
In each form, move the code that process the business logic inside the events as function / procedures in that form.
Then Move these functions/procedures to those classes as static methods.
Finally make only the needed code inside forms like validation UI, and calls to the classes.
For the global variables try to omit as much as you can, and just pass the values as parameters to the methods.
I used static methods, because it's easier for you to remove the code from events and just call them without requiring to Create/Free object for each operation. The original design was not designed to separate the forms from business logic code.
The final application was not full OO, but it least it was easier to test the methods without requiring interacting with the forms and events like before.
Sometimes you feel if you redesign the application from scratch it will be easier than to made changes to make it real OO design.
Another book I can highly, highly recommend - in my personal opinion even better suited than the "generic" refactoring book by Fowler - is "Working Effectively with Legacy Code" by Michael Feathers. It truly showcases the major bumps you will hit while doing that kind of work. Oh, and: Refactoring legacy code can be quite hard on your psyche. I hope you can handle frustration... I like this quote (don't remember where I got it from): "God was able to create the world in 6 days, just because there wasn't any legacy code". Good luck. ;)
Importing into Modelmaker is my first action when confronted with an existing Delphi project. Modelmaker will assist you in refactoring your code because:
It graphically represents all the classes, methods, variables, etc.
It is very tightly integrated in the Delphi IDE (main menu, popup menu,
separate Modelmaker explorer,
toolbar, keyboard shortcuts). This
integration allows you to quickly
perform the necessary actions without
leaving the IDE
It has a dedicated "refactoring" module allowing you to quickly create, move
and rename classes and variables without
having to worry about changing the
underlying code. Modelmaker will
automagically change names and
references in all units.
The basic functionality of Modelmaker is easy to learn. Modelmaker is like any other good productivity tool - The more you put into it, the more you get out of it.
Modelmaker is not free but easily pays for itself in increased productivity.
I have not found a better tool for refactoring legacy Delphi code. They offer a free trial and some decent tutorial movies.
Give Modelmaker a try and good luck...
After understand what you need to refactory your code, and if you want an OPF/ORM, I suggest Jazz SDK
Can anyone (maybe an XSL-fan?) help me find any advantages with handling presentation of data on a web-page with XSL over ASP.NET MVC?
The two alternatives are:
ASP.NET (MVC/WebForms) with XSL
Getting the data from the database and transforming it to XML which is then displayed on the different pages with XSL-templates.
ASP.NET MVC
Getting the data from the database as C# objects (or LinqToSql/EF-objects) and displaying it with inline-code on MVC-pages.
The main benefit of XSL has been consistent display of data on many different pages, like WebControls. So, correct me if I'm wrong, ASP.NET MVC can be used the same way, but with strongly typed objects. Please help me see if there are any benefits to XSL.
I can see the main benefit of employing XSLT to transform your data and display it to the user would be the following:
The data is already in an XML format
The data follows a well defined schema (this makes using tools like XMLSpy much easier).
The data needs to be transformed into a number of different output formats, e.g. PDF, WMP and HTML
If this is to be the only output for your data, and it is not in XML format, then XSLT might not be the best solution.
Likewise if user interaction is required (such as editing of the data) then you will end up employing back-end code anyway to handle updates so might prove one technology too far...
I've always found two main issues when working with XML transformations:
Firstly they tend to be quite slow, the whole XML file must be parsed and validated before you can do anything with it. Being XML it's also excessively verbose, and therefore larger than it needs to be.
Secondly the way transformations work is a bit of a pain to code - custom tools like XmlSpy help, but it's still a different model to what most developers are used to.
At the moment MVC is very quick and looking very promising, but does suffer from the traditional web-development blight of <% and %> bee-stings all over your code. Using XML transformations avoids that, but is much harder to read and maintain.
I've used that technique in the past, and there are applications where we use it at my current place of employment. (I will admit, I am not totally a fan of it, but I'll play devil's advocate) Really that is one of the main advatages, and pushing this idea can be kinda neat. You're able to dynamically create the xsl on the fly and change the look and feel of the page on a whim. Is it possible to do this through the other methods...yes, but it's really easy to build a program to modify an xml/xsl document on the fly.
If you think of using XSL to transform one xml document to another and displaying it as html (which is really what you're doing), you're opening up your system to allow other programs to access the data on the page via XML. You can do this through the other methods, but using an xsl transformation forces it to output xml every time.
I would tread lightly with creating a system this way. You'll find a lot of pit falls you aren't expecting, and if you don't know xsl really really well, there is going to be a learning curve also.
Check this out if you want to use XSLT and ASP.MVC
http://www.bleevo.com/2009/06/aspnet-mvc-xslt-iviewengine/
Jafar Husain offers a few advantages in his proposal for Pretty XSL, primarily caching of the stylesheet to increase page load and reduce the size of your data. Steve Sanderson proposed a slightly different approach using JavaScript as the controller here.
Another, similar approach would be to use XForms, though the best support for it is through a JavaScript library.
If you only going to display data from DB XSL templates may be convenient solution, but if you gonna handle user interaction. Hm... I don't think it'll be maintainable at all.