Question: I am a beginner in Selenium WebDriver (Java with TestNg). I'm trying to create a framework of my own.

My question here is what would be the better option to store my objects (basically all the webelements of my website under test), Page Object Model or External Property file? Why? Is there a better method than those?
Please help.

Answer: 
In my framework, I do not write code for any of the the webelements. I just store the locators (it is in Python, so simple dictionary literal works pretty well) in pageobject file for the page. I generate webelement from that as I need them - this saves lots of code. I could pretend I use factory pattern, but I don't - it is all much simpler than that, because Python's dynamic typing ignores type nazis and makes difficult things simple.

My advice would be not to start with framework. Start with coding what you need, and refactor as you learn more what your code need. Unless you are really experienced Java hacker with lots of OO design experience - and if you were, you would not be asking this question here, I guess? :-)
Given that your are using Java I would go with page object methods.
For the way they are used, either approach will work.  

For example I have converted tests and in one form I was using variables:

```
storedVars["css_phone"] = "css=input[name='auto_policy[phone]']";
storedVars["css_email"] = "css=input[name='auto_policy[email]']";
storedVars["css_street"] = "css=input[name='auto_policy[street]']";

```

and in the other approach these became (ruby) page object methods:

```
def css_phone
  "input[name='auto_policy[phone]']"
end  

def css_email
  "input[name='auto_policy[email]']"
end  

def css_street_address
  "input[name='auto_policy[street_address]']"
end  

```

but their use was essentially the same. 

The important thing to focus on was creating good unique selectors that would not be brittle.

Page Objects are great in the right circumstances. They allow growth.

Initially when you only have a few fields on one page, they are not of much use. Each field is probably fairly unique already and identifying them is trivial and short.

As the application grows the following starts to happen:

* the same field is in multiple spots on the same page
* the same field or collection of fields are on different pages, e.g. many 'help' or 'login' buttons.
* the number of fields grows and different approaches by developers leads to style clashes.
* the correct way to identify elements become a longer string of finders cluttering up the test
* names of fields and containers change over time, sometimes consistently, other times not
* more business logic is added.

In these circumstances having the selector finders embedded in the test code leads to brittle, duplicate, error-prone, hard to maintain code.

Centralizing them in one place addresses these issues and helps:

* reduce duplication
* clarify readability of actual tests
* separate business logic from selector identification
* help reduce change and churn due to layout and styling changes
* encourages the same approach as all the selectors are in one spot

For example if selectors appear on multiple pages, page objects will help guide you to one identifier, such as id, that will be usable. You'll be forced to think about good naming and name spacing up front.