tourze/diy-page-bundle

广告位、装修

0.0.1 2025-06-03 10:06 UTC

Requires

• php: ^8.1
• doctrine/collections: ^2.3
• doctrine/dbal: ^4.0
• doctrine/doctrine-bundle: ^2.13
• doctrine/doctrine-fixtures-bundle: ^4.0
• doctrine/orm: ^3.0
• doctrine/persistence: ^3.1 || ^4
• knplabs/knp-menu: ^3.7
• monolog/monolog: ^3.1
• nesbot/carbon: ^2.72 || ^3
• psr/log: ^3|^2|^1
• symfony/config: ^6.4
• symfony/dependency-injection: ^6.4
• symfony/doctrine-bridge: ^6.4
• symfony/event-dispatcher-contracts: ^2.5 | ^3
• symfony/expression-language: ^6.4
• symfony/http-kernel: ^6.4
• symfony/security-bundle: ^6.4
• symfony/security-core: ^6.4
• symfony/serializer: ^6.4
• tourze/arrayable: 0.0.*
• tourze/bundle-dependency: 0.0.*
• tourze/doctrine-async-bundle: 0.1.*
• tourze/doctrine-indexed-bundle: 0.0.*
• tourze/doctrine-ip-bundle: 0.0.*
• tourze/doctrine-snowflake-bundle: 0.1.*
• tourze/doctrine-timestamp-bundle: 0.0.*
• tourze/doctrine-track-bundle: 0.1.*
• tourze/doctrine-user-bundle: 0.0.*
• tourze/easy-admin-attribute: 0.1.*
• tourze/easy-admin-menu-bundle: 0.1.*
• tourze/json-rpc-cache-bundle: 0.1.*
• tourze/json-rpc-core: 0.0.*
• tourze/symfony-ecol-bundle: 0.1.*
• tourze/symfony-schedule-entity-clean-bundle: 0.1.*
• yiisoft/arrays: ^3

Requires (Dev)

• phpstan/phpstan: ^2.1
• phpunit/phpunit: ^10.0

MIT

README

基于 Page、Block、Element 构建的模块

设计参考：

• http://www.woshipm.com/pd/2028587.html
• https://www.shangtaoyun.net/mnewsdetail-1006.html

TODO

1. 针对地区设定不同的广告信息
2. 针对用户登记设定不同的广告信息
3. 不同时段不同的广告信息

关于装修与专题的方案

装修：

之前我们的装修的设计想法主要是通用性，以及期望是减少体积（尽可能不增加定制页面），例如一个单页面，服务端可以DIY不同的组件组合，前端只需要根据配置去渲染不同的组件，但是按照这种做法，我们会发现前端对于组件的维护就比较艰难了，逻辑很多，这样也会带来页面渲染的性能问题。 后来APP项目做了重构，所有模块都拆分出来了，那么对于一些简单的定制页面还是可以单独维护的。装修的页面应该是一个通用且简单的页面，如果涉及太多的业务逻辑的就不太适合装修的了，我们之前是对一些比较偏业务的页面也实现了装修能力，但本质上我们解决仅仅是代码复用的问题。 装修的组件应该尽可能的少业务，只负责渲染，纯粹一些，可以参考下竞品的装修设计，那这样的话，装修模块要梳理一次的了。

专题

目前我们的专题是主要是渲染一些图片块，定义期望图片产生的行为。我觉得跟装修还是有区别的，如果专题仅仅是负责图片的渲染，那么可以合并到装修模块，但是很多时候，一场活动的专题，往往会期望产生很多的不同的行为，例如：各自环境的调整问题、一些定制的能力。 如果合并到装修的话，一个通用的ImageItem 组件就要处理很多的逻辑了且有些可能是解决不了的，例如专题活动往往会有时效性？如果合并到装修如何理解？另外合并到装修，图片的跳转行为又要多很多的约定了，就不单单是跳转路径的问题。如果后续需要对专题进行报表统计，合并到装修也并不好处理。 如果没有一个很好的设计方案，暂时不太建议合并到装，而是应该拆分出来。如果强行把专题合并到装修也不是不可以，简单就是把专题的能力移植到装修中去，做好各种兼容。