Prepare 2.0 about prestasitemapbundle HOT 16 CLOSED

Situation

• The Bundle is doing the job well
• We had some difficulties making the Bundle evolve (Symfony 2.1, PHP 5.3, issues opened 3 years ago...)
• There is lot of issues, caused by it's lack of flexibility
• The Bundle lack of tests
• Core team is not part of Prestaconcept anymore

Conclusion

We need a new major version. Why ?

• We still believe in this Bundle and we hope the community still want us to improve it
• The code itself is not ready to evolve as we/you need
• We need to build a new team around this bundle, and this team has to trust/believe the code

Solution

So far the bundle has to few components, and to few abstractions.
First thing is to write a more flexible code structure.

What is this all about : generating site maps (thank you captain ^^)

How do we do that :

• Collecting sitemap nodes (as POPO) around the whole application
• Optionnaly Store the result somewhere
• Serializing these nodes to an XML file
• Optionnaly Store the file somewhere
• Serve the file

To me, each step must have its own dedicaded component, with less responsability and a dedicated interface for it :

SitemapCollectorInterface

Many instances for each application.
The responsability of this component is to collect (some way) node elements and add it to the sitemap.

Examples :

• Triggering an event to the Symfony's EventDispatcher component
• Using Symfony's Routing component to extract routes configured to be added
• your need here...

SitemapNodeStorageInterface

Single instance for each application.
The reponsability of this component is to store (some way) collected node elements to avoid re-trigerring the collect.

Examples :

• Using a provider from DoctrineCacheBundle
• Using a client from SncRedisBundle
• your need here...

SitemapSerializerInterface

Single instance for each application.
The reponsability of this component is to serialize (some way) collected (or stored) node elements as an XML string.

Examples :

• Using a dedicated component that will re-use current rules
• Using the Symfony's Serializer component
• your need here...

SitemapFileStorageInterface

Single instance for each application.
The reponsability of this component is to store (some way) XML serialized sitemap to avoid re-serializing it.

Examples :

• Using a provider from DoctrineCacheBundle
• Using a client from SncRedisBundle
• your need here...

If everyone agree with this king a refactoring, I will take some time to implement it.

from prestasitemapbundle.

@esion @alain-flaus @Koc it would be appreciated if somone can provide some complex sitemap examples make sure we don't break anything during the refactoring

from prestasitemapbundle.

I think that has no sense depends on https://github.com/snc/SncRedisBundle or https://github.com/doctrine/DoctrineCacheBundle . Just add dependency to https://github.com/doctrine/cache/blob/master/lib/Doctrine/Common/Cache/Cache.php interface. Especially if we want extract Sitemap component from bundle for getting possibility use it in thirdparty projects like Silex/Laravel/etc

from prestasitemapbundle.

@Koc I don't intend to depend on any third-party bundle/library. Everything will be registered as a suggest.
In fact, this is what the rework is all about, the core component will not rely on third party components, but on adapters.
We can add the component/bundle split to the roadmap of the 2.0 (now or never to me), but I'm not familiar with Silex/Laravel or other things, I cannot provide support for these frameworks.

from prestasitemapbundle.

@yann-eugone if we make a component any body can use it at standalone and we don't have to care if it's Lavarel, zend, drupal.....

they will have to make their own abstraction to use it like we do with a bundle in sf.

So as you said now or never, I would suggest now ?

from prestasitemapbundle.

@nicolas-bastien are right, I propose split sitemap generation from integration with Symfony. Make framework-agnostic library which uses symfony/{event-dispatcher,console,filesystem}

from prestasitemapbundle.

Collecting sitemap nodes (as POPO) around the whole application
Serializing these nodes to an XML file

I think that collecting+serializing is wouldn't work on really big sitemaps. For example we have sitemap with 22 parts (50k urls per part). For what do you want to store them? Why not just dump as now?

from prestasitemapbundle.

@Koc but this is done already, but the serialization is done in the POPO (toXml method)...

from prestasitemapbundle.

@esion @alain-flaus @Koc please see https://github.com/prestaconcept/Sitemap/issues/3

from prestasitemapbundle.

abandonned

from prestasitemapbundle.

@yann-eugone a lot of referenced issues in this issue was closed. Shouldn't they to be reopened?

from prestasitemapbundle.

@Koc yes we should reopen everything.

from prestasitemapbundle.

@yann-eugone why 2.0 closed? because lack of activity?

from prestasitemapbundle.

seriously speaking ?
i opened the component several monthes ago, asked all of you for a review, and nothing happened, so i decided to stop it

from prestasitemapbundle.

I do not use sitemap bundle anymore (I do not write PHP anymore).

My 2 cents:

Situation

The Bundle is doing the job well

So yes, probably too much effort to go further. To be more precise, good idea to restart from scratch if technologies evolves too much than debt to paid to make it working on latest PHP version / {put your PHP framework name here}

from prestasitemapbundle.

it's fine to me, i just want to clear the situation in this bundle so everybody can keep using it

from prestasitemapbundle.