Runtime vs. Design/Compile Time

re: Runtime vs. Design/Compile Time

Chris Ortman — Tue, 19 Feb 2008 12:33:05 GMT

I don't know if you ever really need to know that it is one to one.

If I have a customer object and I can call Customer.Name from other code then I can, whether or not there is a column behind there shouldn't matter. If there does happen to be a column in a Customers table called name, then I never needed to declare a property, if not then I did.

re: Runtime vs. Design/Compile Time

Kathleen — Sun, 17 Feb 2008 15:13:33 GMT

Chris,

How do you know which are one to one and which are not, and how that will evolve? How would you create a system where the code accessing teh business object would not need to know anything about its one to one nature so that it oculd change over time?

I never create a class that iterates over the table columns. It always iterates over the definition of a business object which may or may not map directly to the database.

The templates are all design time. By the time we get to runtime, we have a rather large pile of static language code. I'm not sure how that will evolve as I better understand dynamic langauges.

re: Runtime vs. Design/Compile Time

Chris Ortman — Sat, 16 Feb 2008 22:43:24 GMT

I don't think that a business object need map 1:1 with a database. But for cases where you would have a template like

public class <%= table.ToClassName %> {

<% for column in table.columns %>

public <%= column.CLRType %> <%= column.ToPropertyName %> {get; set;}

<% end %>

}

Why do you need to have the template? why not just have the class query the DB and whatever columns it finds those are the properties. Also if I want to add / modify the behavior of a column I can just do that as part of the class.

My example was trying to say that I tell the UI how to lay things out, grid / flow etc. In this case I said grid, so I would need to tell it what goes in each row. When I call input it should look at what :cities refers to and generate an appropriate input field.

I don't know that I'd say a dynamic language is required, but with as sophisticated as your code gen system seems to be it is almost as if you are building your own language on top of VB . If that's the case it seems like why fight with VB when there are languages that have better support for metaprogramming.

re: Runtime vs. Design/Compile Time

Kathleen — Fri, 15 Feb 2008 14:32:32 GMT

Steve,

I see the big picture of deveopment as a huge mess that we divide and conquer. Attacking the biggest problems and removing them leaves room for a better understanding of the next round of simplification if that makes sense.

I think we've got the main extension points for the plumbing pretty well down. Moving into the broader application there is a not to do. I'm not sure of the relative contributions of static langauges, dynamic languages, workflow plug ins, rules engines and other techniques. We, rather obviously, won't solve it all with code generation. And we will definitely be doing a lot with handcrafted code for now. But I'm also excited about the next round which needs to address both bigger and smaller issues than the block of things code generation does a good job with.

Kathleen

re: Runtime vs. Design/Compile Time

Kathleen — Fri, 15 Feb 2008 14:27:42 GMT

Chris,

Thanks for your comments!

I agree on the JavaScript perhaps getting a bad rap due to implementations. It's good to see both efforts to fix that and focus on real tools with the other dynamic languages.

OR/M - whether design or runtime - exists precisely becuase we can't map directly to databases. I know Ruby on Rails does a pretty direct mapping (last I checked it did provide an option for mapping but I never looked under the hood for that. I think demanding databases and business objects directly syncrhonize is a bad idea.

Did you have in mind the lines in your code that are"input cities" etc to manage or something different? I am generating UI's but I'd like to wait that discussion until I get through the current round of stuff and a round of harness stuff. I think there is a lot more interchange of ideas still needed for UI generation.

Is there anything in what you are thinking here that requires a dynamic language to simplify?

Kathleen

re: Runtime vs. Design/Compile Time

Steve Campbell — Thu, 14 Feb 2008 22:37:29 GMT

I agree completely that we want as much as possible in metadata. I actually think we have progressed significantly in our capability to do that. Code-generation tools are much more accessible than they used to be, as is our ability to make that generation dynamic rather than static.

There is always a line though, between what we want the freedom to express in code, and what we want to be the default (unspecified, generated) behavior. It seems like understanding that relationship, and providing natural extension points is still somewhat of a black art. Do Dynamic languages help in doing that?

re: Runtime vs. Design/Compile Time

Chris Ortman — Thu, 14 Feb 2008 20:10:39 GMT

> everyone I know varies between mild distaste and downright hatred for it.

Were people's frustrations with javascript with javascript the language or the poor implementation on the part of browser vendors + the lack of a good debugger?

I think in a dynamic world you don't really need an OR/M...or maybe just a very thin one, because the database itself is used to build the model.

But I think getting the object to the database is just a very small piece. I'm not sure how you would build a GUI, but my vision would be something like:

Entity Address

#custom behaviors, but don't need to declare properties

end

UserInterface AddressForm

layout :grid

row do

input :states, :on_change => :update_cities

end

row do

input :cities

end

row do

command :save, :execute => :save_address

end

def update_cities

cities = Cities.find_for_state :state

reload_input :cities, cities

end

def save_address

Address.save

end

So I totally just made that up, but the idea is that I'm still programming in metadata, but the behind the scenes stuff could figure out to generate WPF form or HTML. I think we're both trying to get to the same place, but I would rather have a programming language *be* my template syntax instead of some form of XML or 'template'