CSS hierarchy wish

Alot, of times I find myself having a wrapper around some elements in my html so that I can do some custom css inside of it. In the css case below the wrapper is a div with a class of "webfolio".

div.webfolio h3{
font-size:1.5em;
color:#333;
}

div.webfolio div.article{
border:1px solid #666;
}

div.webfolio div.description{
color:#555;
}

Notice I have to write "div.webfolio" over and over. I just want to write it once, with everything (it's children) inside of it. I wish I could do it like this:

div.webfolio{

h3{
font-size:1.5em;
color:#333;
}

div.article{
border:1px solid #666;
}

div.description{
color:#555;
}

}

I just feel dirty writing the same name over and over. Yes, I realize if you get more than one or two deep in above css it would get harder to read. In a perfect world this could be prevented by code responsibility.

From SQL to HQL

Most of the development I have done has been with SQL records. Now that CF9 is out I've started playing around with HQL objects and it has been a learning curve but for the best. I struggled and continue to struggle with writing HQL, because my mind still wants to do SQL. I wanted to share what I have learned so far.

Given the db schema below I will show how to write a piece in sql followed by a piece in hql.

There is a PRODUCT table with a many to many relationship with the SIZE table and the PRODUCT table has many to many relationship with the CATEGORY table.

PRODUCT -|-----= PRODUCT_SIZE =------|- SIZE
PRODUCT -|-----= PRODUCT_CATEGORY =-----|- CATEGORY

1. Get all the products
SQL

select * from product

HQL

from Product

2. Get all the products with price equal to $100.
SQL

select * from product where price = '100'

HQL

from Product where price = '100'

3. Get all the products with size_id = 1.
SQL

select * from product 
inner join product_size on product.id = product_size.product_id
where product_size.size_id = 1

HQL

select product
from Product product
join product.sizes size
where size.id = 1

4. Get all the products with size_id = 1 and category_id = 1.
SQL

select * from product 
inner join product_size on product.id = product_size.product_id
inner join product_category on product.id = product_category.product_id
where product_size.size_id = 1
and product_category.category_id = 1

HQL

select product
from Product product
where exists (
from product.categories category
where category.id = 1
)
and exists (
from product.sizes size
where size.id = 1
)

Note: HQL can't solve all queries, a good example is Accounting queries, but it does help with the majority of the light weight queries. I get the line "Well what's the point of using objects if records work fine.". I reply with "There is no point, but if you want to update all your queries with new properties, you will quickly find the point."

Resources used:

http://www.barneyb.com/barneyblog/2010/05/05/embrace-your-hsql/

ColdMVC: Create your own Helpers.

I wanted to try extending ColdMVC's helpers and create my own helper that formatted stuff for me and it turned out to be quite simple.

First, I created my own directory in my project called "helpers".

Second, I added a cfc named "format".

Third, I extended the ViewHelper from ColdMVC. Not sure, If this is the correct Helper Util class I am suppose to be using...but it worked.

<cfcomponent extends="coldmvc.utils.ViewHelper">
 
 <!------>

 <cffunction name="money" access="public" output="false" returntype="any">
  <cfargument name="amount" required="false" default="0"/>
  
  <cfreturn dollarFormat(arguments.amount)/>
 
 
 </cffunction>

 <!------>

</cfcomponent>

Lastly, I used my new helper function:

#$.format.money(product.getPrice())#

If you noticed in money() I set a default value of zero. For some odd reason when I put "product.getPrice()" in for the amount argument it has a value of [empty string] and it throws an error. The error says "The AMOUNT parameter to the money function is required but was not passed in.". But clearly there is a value of [empty string]. If any one knows what up give me hollar.

Entity Name is same for two CFCs

As I have been trying out CF9 and the ColdMVC I occasionally get this error "Entity Name Category is same for two CFCs". Where "Category" is my model cfc. This is ok if I really had two CFC's with the same name. Here's the rest of the error:

Entity Name Category is same for two CFCs, superior.app.model.Category and superior.app.model.Category.

As you can see, the error looks like it's pointing at the same file. Searching up and down my Eclipse project explorer I find no two cfc with the same name. Guess what...do a refresh on your model directory or where ever you put your VO's. You probably have two hibernate files, both containing your VO's name...mine was "Category".

Get rid of one of them and it should work.

Exploring ColdMVC

If you haven't checked out ColdMVC yet you should. It's a light weight ColdFusion ORM framework I've being playing around with. The biggest thing I was impressed with is the tags on the views you can make...I am easily satisfied.

Have you ever been tired of typing that same css container.
Ex:

<div class="buttons">
<!--- some buttons --->
</div>

With ColdMVC's tags that section turns into:

<buttons>
<!--- some buttons --->
</buttons>

The tags help keep the view clean. The only worry that I have NOT ran into yet is that helper tags are very similar to html tags. Not sure how it will play out yet, but no problems so far.

Just Do It : Programming to the Nike Approach.

After reading a recommended book by a friend, I wanted to talk about the Nike's old marketing slogan, "Just Do It.", and it's relationship to my programming experiences. Nike's "Just Do It" slogan really helps me answer those 50/50 questions or "hmm, we could probably use this snippet of code in other places, but I am not sure if it should be reused" or "this might be a pretty good idea, but I am not sure if we have permission to do it." you have when you are programming. Do what you think is right. Basically, JUST DO IT! There have been so many times another programmer or myself have been stuck or afraid of making a business decision becomes of fears of the wrong outcome. The fact is "no one likes to make decisions" period, so presenting it to another person really just causes frustration. So just code it the way you think it needs to be done.

Now, I am not saying you should do this for ever decision but most of the decisions left up to a developer are minor in the eyes of the user. They want you to tell them how they should work and they will tell you what's missing, named wrong, or doesn't work. So I invite you to be bold like Nike and "Just Do It.".

Throw that extra icon or link in there.
Set the smart default you think you would use the most.
Constrain the user to a set of options to choose from to better focus the experience.

Once it's coded and demo-able, have another couple set of eyes look at it. They will tell you what works and doesn't work, but at least you create some discussion on your concern by showing. Showing is such a strong yet hard thing to accomplish in programming, because it's hard to finish something. By getting something to show you are very close if not finished with your task. People aren't dump, they will notice the changes you did and if they don't that means they don't care and your in the clear or you chose "what the user will naturally want" and it will work. Either way it's a silent win for you.

If you spend too much time deciding how something should be done vs. doing it, more and more requests will be added and you will get overwhelmed with tasks. Just code it and demo it to a group of people, whom will spend the next week ripping and tweaking the piece you created, until they figure out what they want. Where this kinda sucks cause you will have to go back and look at your code, you will find out what worked and didn't, be able to create some direction for your self by involving others in your concerns, and be more prepared for the next task for which you can transfer the tips you learned. It also allows you to focus more on code instead of managing politics.

In recap...Just Do It!

Simplicity vs. DRY code

I was in a pickle today over whether or not to consolidate code or keep it a little bit wet for simplicity sake. I consider simplicity sake, going to a view and not having to unlock the rubric's cube of "if" logic. If you are not familiar with wet and dry code, wet is where you repeat yourself over and over and dry is where you "Don't Repeat Yourself (DRY)". I went with "Simplicity". I decided to consolidate parts of the view, yet repeat myself a little. I found this to be safe because I felt like the views would grow and I didn't want it to end up with a crazy page that only the maker has the key to unlocking its craziness. Yeah, we have all seen some of those old pages that are a disaster to debug and I didn't want to start that trend. Also, I wanted the next person behind me to get in and out of the view as quickly as possible. It wasn't very much fun going through every view and updating the same piece of code...but it was simple.