Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refacttored HTML5 class & added HTML5 Helper with static methods #37

Merged
merged 2 commits into from
Jun 11, 2014
Merged

Refacttored HTML5 class & added HTML5 Helper with static methods #37

merged 2 commits into from
Jun 11, 2014

Conversation

goetas
Copy link
Member

@goetas goetas commented May 14, 2014

Refactoring HTML5 class to be as #33 (comment)

@goetas goetas mentioned this pull request May 14, 2014
@technosophos
Copy link
Member

Wow. That was a huge task. Thanks!

I just finished reviewing the last two commits, and largely I'm really happy with this solution. Conceptually, I am now sure this is the right way to go.

Coding convention-wise, there are a few places where new function calls start with the curly brace on the next line. That's the only one I'd really gripe about. We've also tended to start else { on a separate line (because it's easier to comment, and because when we started this we based it on the Drupal coding convetions).

I'll let @mattfarina review, and if @miso-belica wants to give an opinion, too, I'd like to hear it.

I guess now is the time when we need to decide whether we want to do this on a separate branch.

@goetas
Copy link
Member Author

goetas commented May 14, 2014

I have fixed some code stye issues.

New branch, things to do (in my opinion):

  1. I suggest to merge Tests PSR compatible #34 into master branch.
  2. Merge 1.0 as master dev branch #38
  3. Optionally you can also create the 1.0.5 tag
  4. Fork the master branch and call it 1.0
  5. Increment composer version to 2.0-dev into composer.json on master branch (same as 1.0 as master dev branch #38)
  6. When ready, merge this PR
  7. I'm also working on a PR to make html5 compatible with HHVM
  8. Create the 2.0.0 tag

@goetas
Copy link
Member Author

goetas commented May 14, 2014

Can be also a good idea switch also to Mastermids namespace (Mastermids\HTML5)?
We are breaking compatibility with 1.0, this is the right time to break also this!

/**
* Global options for the parser and serializer.
* @var array
*/
public static $options = array(

private $options = array(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason $options is private rather than protected? Isn't protected more appropriate?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

protected equals to "hidden" dependency.
When someone extends HTML5 class, we can't change it's internal implementation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the visibility is private (where only the class that defines it can access it) methods that use it can't be overridden and still have access to the options (including the constructor). An extending class can't change the defaults.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can replace all uses of $this->options with $this->getOptions(). Can be a solution?

You can overwrite getOptions method changing the default values..

@mattfarina
Copy link
Member

@goetas Thanks for working on this.

I agree with @technosophos that this is a good way to go. It seems sane.

@goetas It's common for a projects namespacing to not include the vendor. What is your case for making the switch? I'm not fundamentally opposed to the idea but I'd like to know your case.

@goetas
Copy link
Member Author

goetas commented May 19, 2014

Just a "convention" issue. I think that exists somewhere, a developer that has created a class called HTML5. This developer can't use html5-php project (class names conflict).

Adding a namespace prefix, we will become more standard & compatible with the world.

@goetas
Copy link
Member Author

goetas commented May 23, 2014

Can it be ready to be merged?

@goetas goetas changed the title [WIP] New error handling Refacttored HTML5 class & added HTML5 Helper with static methods May 23, 2014
@mattfarina
Copy link
Member

@goetas I'll take a look at this in the next day or so. We had a holiday weekend and then I was under the weather.

@goetas
Copy link
Member Author

goetas commented May 28, 2014

@mattfarina don't worry! :)

@mattfarina
Copy link
Member

FYI, since this makes API changes my thought is to get a couple other non-api changing bug fixes in and create another 1.x release. Then make a 1.0 branch. Turn master into a 2.x-dev branch and merge this api changer in (note, i still need to finish my last review).

@goetas goetas mentioned this pull request May 30, 2014
@goetas
Copy link
Member Author

goetas commented Jun 2, 2014

Just a little question: is HTML5Helper really needed?

Since we are breaking compatibility with 1.0, we could avoid this... At the moment there is no real real reason to preserve this class except for compatibility ...

@goetas
Copy link
Member Author

goetas commented Jun 2, 2014

At the moment this class represents 200 lines of code that needs to be mantained, without a real benefit

@technosophos
Copy link
Member

I don't have a strong opinion about the HTML5Helper class. Personally, I probably wouldn't use it (which is probably a good indicator that it is unnecessary). But it does at least superficially make the new API look like the old one.

@goetas
Copy link
Member Author

goetas commented Jun 2, 2014

@mattfarina?

@mattfarina
Copy link
Member

I had the exact same thought at @technosophos.

While I won't use it, would it be useful to have the new API look like the old one?

@goetas
Copy link
Member Author

goetas commented Jun 3, 2014

Since we are breaking compatibility, new users should learn to use new HTML5 api.

@goetas goetas mentioned this pull request Jun 4, 2014
@technosophos
Copy link
Member

Okay. Let's definitely get rid of the statics.

@miso-belica
Copy link
Contributor

@technosophos 👍 🍰

@cognifloyd
Copy link
Contributor

+1 to adding the Masterminds namespace. It feels cleaner that way.

Oh, and this change will make it much easier to use this in a project I'm working on, where I suspect I'll have to extend the html5 parser to support xml-like namespaces for some template generation (something that the basic html5 lib doesn't need). Thanks!

@@ -83,18 +91,17 @@ public static function loadHTML($string) {
* PHP DOM implementation. It simply calls load().
*
* @param string $file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You changed the param to $string

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@goetas goetas mentioned this pull request Jun 9, 2014
@goetas goetas added this to the 2.0 milestone Jun 10, 2014
goetas added a commit that referenced this pull request Jun 11, 2014
Refactored HTML5 class, removed static methods
@goetas goetas merged commit 10c06d9 into Masterminds:master Jun 11, 2014
goetas added a commit that referenced this pull request Jun 11, 2014
@goetas goetas deleted the new-error-handling branch June 16, 2014 10:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants