Bob Ward 8年 前 We have been very interested in this topic as it directly relates to IT trying to accommodate our Marketing dept requirements to: 1. QA our www site with all the content in place (execs can't review with ipsum lorem content) 2. not recreate content on more than one environmentOn the IT side we don't want to keep content in sync between environments as this is more work.We would completely buy into the concept of using our PROD staging site as the QA location but we have a challenge and that is our design approach frequently requires a theme deployment in order to accommodate new pages and/or template updates. This is prohibiting the flexibility we want to have in using the staging site.I have been told we included most of the CSS and javascript in the theme in order to consolidate code and improve performance. We have about 15 templates on the main site ... reengineering them to gain the flexibility we want may be a lot.We would be interested in any thoughts or suggestions .. IT would certainly like to give Marketing the flexibility and QA ability but we can't risk frequent theme deployments to PROD. Those deployments need to be controlled and monitored by IT. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Bob Ward 8年 前 That is a tough one, Bob...Normally you'd see the theme get created and deployed, but afterwards the content creation would be based upon the theme.Sure the theme would need to be tweaked from time to time but one would expect some stability of the theme over time.That of course is probably the 80% of the 80/20 rule, and it sounds like you're in the 20% category.Would it be possible to take advantage of some of the other styling support Liferay offers? Look and feel/advanced tab for the web content display or embedded styles within the content article itself? 投票するためにはログインが必要です。 次として送信する: キャンセル Traolly Xiong David H Nebinger 8年 前 Hello David, Having the CSS / JS in the theme improves the performance on our site in many ways (i.e. merging CSS, combining JS, minification, compression, cacheable of external resources on CDNs and locally, lighter page sizes, fewer HTTP requests in which will allow more browser parallel connections and mitigate blocking other requests, etc.). The templates will mainly just have HTML markup and Freemarker code with little embedded CSS / JS for unique use cases. Doing this would also almost eliminate duplicated CSS / JS code in templates. For a global company with a rich and robust site that is also responsive, users would find this design more beneficial especially for users with a slower internet / mobile network connection. With that said, I had a few questions if you don't mind. 1) If we do move the CSS / JS from theme into the web content display portlet config "look/feel", it would seem that we would have to add it each and every portlet as they are unique even if when they rendering the same content. That would be tedious work, correct? Would you agree if keeping them in sync would also be harder to manage? I would think the same would apply to the web content itself approach as well. 2) If we do move the CSS / JS from the theme to the portal level (templates, portlet config, web content itself, portal pages overrides, etc.), how do we avoid duplicate / redundant CSS / JS as that wouldn't allow us to thin out the page size or cache the CSS / JS, and potentially cause js conflicts?3) Part of the 80/20 you mentioned, how would you best describe their (80%) development process with the minimal theme updates / deploymentsand also have a good front-end performance experience?Let us know your wise thoughts of if you need any more info. Thanks in advance. Traolly 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Traolly Xiong 8年 前 Hey, Traolly.Certainly you want to do your styling in the theme because it has those advantages and also promotes uniformity within your content.I was proposing it for Bob only because his group would be stuck waiting for IT to deliver theme changes and have to do a coordinated release. In his situation it may make more sense to look at an alternate approach than straight theming. Even if they go about putting styling in the content or page, I would still suggest sending it to IT to integrate in the theme. When (if) they do the next theme deployment, the styling can be shared with content delivered later.I am certainly not recommending that we all stop using a theme for the styling, putting the styling into the page or the content for most of us is definitely the wrong thing to do.All of your criticism of this is spot on. I'm sure if we put our heads together we could knock out a few more ways in which moving styling out of the theme would prove problematic.This was a suggestion really to help Bob separate the content creation from the development process. Sounds like he's got a fast-moving marketing group that needs to set up and maintain content that would change often, far more often than an IT project cycle for theme deployment. In his situation it may be better for him to allow for duplicate or redundant styling, etc. If that's the price to pay for being able to keep up with their necessary site changes, well then it is what it is.For the 80% of us (well, it's probably a lot more than 80% but that doesn't have a nice rule like the 80/20 one), we're going to engage our theme folks early in the site process. They'll lay out the design, create all of the styling and hand a list of classes to the content folks so they can decorate the content appropriately.Most of the time the theme gets done and it will have minor changes afterwards, oddball things to make a piece of content work or a tweak for a browser issue, etc. But in general the theme should work until your next big redesign (in some cases that redesign will never come, so don't hold your breath waiting for it).So in this slot, the folks doing the various roles of web content publication can leverage the inline editor, the workflow approval process, and staging (local or remote) to happily complete the publication process. 投票するためにはログインが必要です。 次として送信する: キャンセル Traolly Xiong David H Nebinger 8年 前 As always thanks for the response. We may just have to prioritize what we really want, and adjust our design and process that will make all parties content. There's going to be trade offs regardless of the approach and we just have to find the middle ground. Thanks. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Bob Ward 8年 前 That is a tough one, Bob...Normally you'd see the theme get created and deployed, but afterwards the content creation would be based upon the theme.Sure the theme would need to be tweaked from time to time but one would expect some stability of the theme over time.That of course is probably the 80% of the 80/20 rule, and it sounds like you're in the 20% category.Would it be possible to take advantage of some of the other styling support Liferay offers? Look and feel/advanced tab for the web content display or embedded styles within the content article itself? 投票するためにはログインが必要です。 次として送信する: キャンセル Traolly Xiong David H Nebinger 8年 前 Hello David, Having the CSS / JS in the theme improves the performance on our site in many ways (i.e. merging CSS, combining JS, minification, compression, cacheable of external resources on CDNs and locally, lighter page sizes, fewer HTTP requests in which will allow more browser parallel connections and mitigate blocking other requests, etc.). The templates will mainly just have HTML markup and Freemarker code with little embedded CSS / JS for unique use cases. Doing this would also almost eliminate duplicated CSS / JS code in templates. For a global company with a rich and robust site that is also responsive, users would find this design more beneficial especially for users with a slower internet / mobile network connection. With that said, I had a few questions if you don't mind. 1) If we do move the CSS / JS from theme into the web content display portlet config "look/feel", it would seem that we would have to add it each and every portlet as they are unique even if when they rendering the same content. That would be tedious work, correct? Would you agree if keeping them in sync would also be harder to manage? I would think the same would apply to the web content itself approach as well. 2) If we do move the CSS / JS from the theme to the portal level (templates, portlet config, web content itself, portal pages overrides, etc.), how do we avoid duplicate / redundant CSS / JS as that wouldn't allow us to thin out the page size or cache the CSS / JS, and potentially cause js conflicts?3) Part of the 80/20 you mentioned, how would you best describe their (80%) development process with the minimal theme updates / deploymentsand also have a good front-end performance experience?Let us know your wise thoughts of if you need any more info. Thanks in advance. Traolly 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Traolly Xiong 8年 前 Hey, Traolly.Certainly you want to do your styling in the theme because it has those advantages and also promotes uniformity within your content.I was proposing it for Bob only because his group would be stuck waiting for IT to deliver theme changes and have to do a coordinated release. In his situation it may make more sense to look at an alternate approach than straight theming. Even if they go about putting styling in the content or page, I would still suggest sending it to IT to integrate in the theme. When (if) they do the next theme deployment, the styling can be shared with content delivered later.I am certainly not recommending that we all stop using a theme for the styling, putting the styling into the page or the content for most of us is definitely the wrong thing to do.All of your criticism of this is spot on. I'm sure if we put our heads together we could knock out a few more ways in which moving styling out of the theme would prove problematic.This was a suggestion really to help Bob separate the content creation from the development process. Sounds like he's got a fast-moving marketing group that needs to set up and maintain content that would change often, far more often than an IT project cycle for theme deployment. In his situation it may be better for him to allow for duplicate or redundant styling, etc. If that's the price to pay for being able to keep up with their necessary site changes, well then it is what it is.For the 80% of us (well, it's probably a lot more than 80% but that doesn't have a nice rule like the 80/20 one), we're going to engage our theme folks early in the site process. They'll lay out the design, create all of the styling and hand a list of classes to the content folks so they can decorate the content appropriately.Most of the time the theme gets done and it will have minor changes afterwards, oddball things to make a piece of content work or a tweak for a browser issue, etc. But in general the theme should work until your next big redesign (in some cases that redesign will never come, so don't hold your breath waiting for it).So in this slot, the folks doing the various roles of web content publication can leverage the inline editor, the workflow approval process, and staging (local or remote) to happily complete the publication process. 投票するためにはログインが必要です。 次として送信する: キャンセル Traolly Xiong David H Nebinger 8年 前 As always thanks for the response. We may just have to prioritize what we really want, and adjust our design and process that will make all parties content. There's going to be trade offs regardless of the approach and we just have to find the middle ground. Thanks. 投票するためにはログインが必要です。 次として送信する: キャンセル
Traolly Xiong David H Nebinger 8年 前 Hello David, Having the CSS / JS in the theme improves the performance on our site in many ways (i.e. merging CSS, combining JS, minification, compression, cacheable of external resources on CDNs and locally, lighter page sizes, fewer HTTP requests in which will allow more browser parallel connections and mitigate blocking other requests, etc.). The templates will mainly just have HTML markup and Freemarker code with little embedded CSS / JS for unique use cases. Doing this would also almost eliminate duplicated CSS / JS code in templates. For a global company with a rich and robust site that is also responsive, users would find this design more beneficial especially for users with a slower internet / mobile network connection. With that said, I had a few questions if you don't mind. 1) If we do move the CSS / JS from theme into the web content display portlet config "look/feel", it would seem that we would have to add it each and every portlet as they are unique even if when they rendering the same content. That would be tedious work, correct? Would you agree if keeping them in sync would also be harder to manage? I would think the same would apply to the web content itself approach as well. 2) If we do move the CSS / JS from the theme to the portal level (templates, portlet config, web content itself, portal pages overrides, etc.), how do we avoid duplicate / redundant CSS / JS as that wouldn't allow us to thin out the page size or cache the CSS / JS, and potentially cause js conflicts?3) Part of the 80/20 you mentioned, how would you best describe their (80%) development process with the minimal theme updates / deploymentsand also have a good front-end performance experience?Let us know your wise thoughts of if you need any more info. Thanks in advance. Traolly 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Traolly Xiong 8年 前 Hey, Traolly.Certainly you want to do your styling in the theme because it has those advantages and also promotes uniformity within your content.I was proposing it for Bob only because his group would be stuck waiting for IT to deliver theme changes and have to do a coordinated release. In his situation it may make more sense to look at an alternate approach than straight theming. Even if they go about putting styling in the content or page, I would still suggest sending it to IT to integrate in the theme. When (if) they do the next theme deployment, the styling can be shared with content delivered later.I am certainly not recommending that we all stop using a theme for the styling, putting the styling into the page or the content for most of us is definitely the wrong thing to do.All of your criticism of this is spot on. I'm sure if we put our heads together we could knock out a few more ways in which moving styling out of the theme would prove problematic.This was a suggestion really to help Bob separate the content creation from the development process. Sounds like he's got a fast-moving marketing group that needs to set up and maintain content that would change often, far more often than an IT project cycle for theme deployment. In his situation it may be better for him to allow for duplicate or redundant styling, etc. If that's the price to pay for being able to keep up with their necessary site changes, well then it is what it is.For the 80% of us (well, it's probably a lot more than 80% but that doesn't have a nice rule like the 80/20 one), we're going to engage our theme folks early in the site process. They'll lay out the design, create all of the styling and hand a list of classes to the content folks so they can decorate the content appropriately.Most of the time the theme gets done and it will have minor changes afterwards, oddball things to make a piece of content work or a tweak for a browser issue, etc. But in general the theme should work until your next big redesign (in some cases that redesign will never come, so don't hold your breath waiting for it).So in this slot, the folks doing the various roles of web content publication can leverage the inline editor, the workflow approval process, and staging (local or remote) to happily complete the publication process. 投票するためにはログインが必要です。 次として送信する: キャンセル Traolly Xiong David H Nebinger 8年 前 As always thanks for the response. We may just have to prioritize what we really want, and adjust our design and process that will make all parties content. There's going to be trade offs regardless of the approach and we just have to find the middle ground. Thanks. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Traolly Xiong 8年 前 Hey, Traolly.Certainly you want to do your styling in the theme because it has those advantages and also promotes uniformity within your content.I was proposing it for Bob only because his group would be stuck waiting for IT to deliver theme changes and have to do a coordinated release. In his situation it may make more sense to look at an alternate approach than straight theming. Even if they go about putting styling in the content or page, I would still suggest sending it to IT to integrate in the theme. When (if) they do the next theme deployment, the styling can be shared with content delivered later.I am certainly not recommending that we all stop using a theme for the styling, putting the styling into the page or the content for most of us is definitely the wrong thing to do.All of your criticism of this is spot on. I'm sure if we put our heads together we could knock out a few more ways in which moving styling out of the theme would prove problematic.This was a suggestion really to help Bob separate the content creation from the development process. Sounds like he's got a fast-moving marketing group that needs to set up and maintain content that would change often, far more often than an IT project cycle for theme deployment. In his situation it may be better for him to allow for duplicate or redundant styling, etc. If that's the price to pay for being able to keep up with their necessary site changes, well then it is what it is.For the 80% of us (well, it's probably a lot more than 80% but that doesn't have a nice rule like the 80/20 one), we're going to engage our theme folks early in the site process. They'll lay out the design, create all of the styling and hand a list of classes to the content folks so they can decorate the content appropriately.Most of the time the theme gets done and it will have minor changes afterwards, oddball things to make a piece of content work or a tweak for a browser issue, etc. But in general the theme should work until your next big redesign (in some cases that redesign will never come, so don't hold your breath waiting for it).So in this slot, the folks doing the various roles of web content publication can leverage the inline editor, the workflow approval process, and staging (local or remote) to happily complete the publication process. 投票するためにはログインが必要です。 次として送信する: キャンセル Traolly Xiong David H Nebinger 8年 前 As always thanks for the response. We may just have to prioritize what we really want, and adjust our design and process that will make all parties content. There's going to be trade offs regardless of the approach and we just have to find the middle ground. Thanks. 投票するためにはログインが必要です。 次として送信する: キャンセル
Traolly Xiong David H Nebinger 8年 前 As always thanks for the response. We may just have to prioritize what we really want, and adjust our design and process that will make all parties content. There's going to be trade offs regardless of the approach and we just have to find the middle ground. Thanks. 投票するためにはログインが必要です。 次として送信する: キャンセル
Adnan Yaqoob 8年 前 David,To my knowledge it is a good practice to have staging server for content authoring. On staging server your content editor create/modify the contents. The whole site can be simulated with content and any custom development including themes.If everything looks good the publisher cane push the content to production site ( in Liferay using Publish to Live).Are you suggesting to use Production server directly for content editing? if yes wouldn't it effect performance on production? Generally Production servers are not use for content authoring, please suggest. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Adnan Yaqoob 8年 前 Certainly not, Staging is definitely appropriate for that activity.This was a post arguing in favor of using staging for your content creation bound to your production instance.It was in response to a post in the forums that was about, IIRC, using LARs to export content created in a dev environment and pushing through to prod and how they were having issues getting the LARs to import correctly in each environment.If you're using staging, either local or remote, for your content creation and then publishing live to your production site, you are spot on with your process, doing things the Liferay way. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Adnan Yaqoob 8年 前 Certainly not, Staging is definitely appropriate for that activity.This was a post arguing in favor of using staging for your content creation bound to your production instance.It was in response to a post in the forums that was about, IIRC, using LARs to export content created in a dev environment and pushing through to prod and how they were having issues getting the LARs to import correctly in each environment.If you're using staging, either local or remote, for your content creation and then publishing live to your production site, you are spot on with your process, doing things the Liferay way. 投票するためにはログインが必要です。 次として送信する: キャンセル
Adnan Yaqoob 8年 前 Thanks for clarification.In fact I asked the question because I'm in favor doing what I mentioned above. But few fellows who don't know much about content authoring and the standard practices want to permit content authoring directly on production instance. They believe the CMS servers should be able to handle or what's the purpose using CMS.Please advice, if my approach is wrong or ? what will be the performance impact. If Liferay had any document/link suggesting the best practices to use Staging for content authoring and publishing that can help 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Adnan Yaqoob 8年 前 Staging allows you to see a whole page as it will be rendered, prior to publication. Workflow on a web content article allows you to approve individual content, but won't allow you to get a full view until you publish.Staging also allows you to deal with publishing a full page instead of individual approvals.As far as performance goes, well there really shouldn't be a performance impact, at least not a noticeable one. Users, when they access the site, will see the published content and your approvers will see the staged content.Whether to use staging or not, well that should depend upon your organizational requirements. If you have little if any web content or you're not worried about approving and previewing, then staging and workflow are unnecessary overkill. Sometimes workflow is all you need, sometimes just staging, And sometimes neither. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Adnan Yaqoob 8年 前 Staging allows you to see a whole page as it will be rendered, prior to publication. Workflow on a web content article allows you to approve individual content, but won't allow you to get a full view until you publish.Staging also allows you to deal with publishing a full page instead of individual approvals.As far as performance goes, well there really shouldn't be a performance impact, at least not a noticeable one. Users, when they access the site, will see the published content and your approvers will see the staged content.Whether to use staging or not, well that should depend upon your organizational requirements. If you have little if any web content or you're not worried about approving and previewing, then staging and workflow are unnecessary overkill. Sometimes workflow is all you need, sometimes just staging, And sometimes neither. 投票するためにはログインが必要です。 次として送信する: キャンセル
Fernando Fernandez 8ヶ月 前 - 編集済み "LARs are not broken". I beg to differ. :-) Exporting and importing websites is, de facto, a missing feature from Liferay, since ever. Not because it doesn't exist, but because it's so broken it's barely usable. As a Liferay user, it's unacceptable that I cannot export a working website to a different instance of the same Liferay version. As you stated, LAR export/import is full of problems that will make it unusable in many situations. For starters, I think this should be worked on: - Invalid data errors should be handled at export-time, not import-time; tools should be available to detect and solve data errors preemptively - Errors should be made readable by a business user trained in content management; no developer should be needed to decode messages or analyse the DB - Dependencies from stuff outside the site should be clearly listed on an export report: content from other websites, users, roles, global site components, etc.; tools should be made available to export and import those too - Import should not give up on first error: it should try to import as much as possible; an half-imported website might be better than nothing, since there are not many alternatives 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Fernando Fernandez 8ヶ月 前 - 編集済み They're not broken, though, they are just extremely fragile. If you take care when building your site _not_ to depend on resources from the global site or from any other site, and if you take care when exporting your LAR file to include everything that will be needed, you _can_ be successful importing into another instance that is the _exact same version_ and _exact same configuration_ and _exact same customizations_. The problem is that most of us do not take that care. There are benefits of using a global scope. There are benefits to leveraging things from other sites. And it's hard to match version (down to the specifically deployed hotfix) or configuration (i.e. the same languages set up, etc). Broken implies that it would _never_ work. But it does work under a specific set of conditions. Your car isn't broken if it can't drive through a river to get to a town on the other side, it's just not designed to support that. And that's really the crux of the problem. LARs work for the use cases they were designed to support, but they weren't designed to handle many of the use cases we might want to use them for. For some of your suggestions, though, they're not really possible. Such as invalid data, when the export happens it isn't clear that the data is invalid at all. A reference can be part of the export, but the system cannot know that the reference is satisfiable on the target site or not. That's why those things happen at import - only then can you determine if data is invalid or not. The error messages, yeah I'm with you on that one. They're the same kind of messages you get when staging fails and they aren't all that helpful either, but at the same time, useful messages can be hard to render during import. Take a reference to a file that might be on "/folder/folder/folder/Fancy Name" from the source side; the export doesn't include all of those details, just the reference (basically the UUID to match to, maybe the file name). On import, the system will determine that the file is missing, but it can't give you much useful detail. It doesn't know that the filename that it may have is under some specific path on the source side, so often times it is missing enough context to make for a useful error message anyway. External dependencies? Yeah, those are tough. Say you have a global structure X. Sure you could export site Y and maybe include structure X, but problems come if you try to load into an instance where there is already a structure X in the global site. How do you reconcile that? Is it a new version? What happens to content in that instance that is using the current X, how could it handle a new X that might be completely different or even exactly the same? These are the kinds of problems that are at the core of the export/import problem, and many of them are issues with missing/incomplete context or conflict resolution. Both of these are really, really tough problems to solve and you'll likely never get one solution that works for everyone. But that brings us back to the content of this blog post - Liferay isn't designed to support content/site promotion, copying, export/import, etc. And rather than trying to force it and fight it, instead you should ditch that idea and embrace the tools that Liferay does support, including staging and now publications. Build your content in the prod environment in staging or publications, publish it to live when it is ready. Liferay _is_ designed to handle this process, so if you embrace it you'll have a much better time with Liferay than if you try and fight it with export/import attempts. 投票するためにはログインが必要です。 次として送信する: キャンセル Fernando Fernandez David H Nebinger 8ヶ月 前 - 編集済み I understand your arguments and also understand the product strategy, but I cannot agree. Still, for all the difficulties in my proposals, there's at least a couple I think should be easy to solve: 1. import should not give up upon first error, and should try to recover as much as possible from the LAR file 2. errors should be made easier to read and the import process should try to help the common user understand what's wrong These, by themselves, would make a big difference in the usefulness of LARs. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Fernando Fernandez 8ヶ月 前 - 編集済み They're not broken, though, they are just extremely fragile. If you take care when building your site _not_ to depend on resources from the global site or from any other site, and if you take care when exporting your LAR file to include everything that will be needed, you _can_ be successful importing into another instance that is the _exact same version_ and _exact same configuration_ and _exact same customizations_. The problem is that most of us do not take that care. There are benefits of using a global scope. There are benefits to leveraging things from other sites. And it's hard to match version (down to the specifically deployed hotfix) or configuration (i.e. the same languages set up, etc). Broken implies that it would _never_ work. But it does work under a specific set of conditions. Your car isn't broken if it can't drive through a river to get to a town on the other side, it's just not designed to support that. And that's really the crux of the problem. LARs work for the use cases they were designed to support, but they weren't designed to handle many of the use cases we might want to use them for. For some of your suggestions, though, they're not really possible. Such as invalid data, when the export happens it isn't clear that the data is invalid at all. A reference can be part of the export, but the system cannot know that the reference is satisfiable on the target site or not. That's why those things happen at import - only then can you determine if data is invalid or not. The error messages, yeah I'm with you on that one. They're the same kind of messages you get when staging fails and they aren't all that helpful either, but at the same time, useful messages can be hard to render during import. Take a reference to a file that might be on "/folder/folder/folder/Fancy Name" from the source side; the export doesn't include all of those details, just the reference (basically the UUID to match to, maybe the file name). On import, the system will determine that the file is missing, but it can't give you much useful detail. It doesn't know that the filename that it may have is under some specific path on the source side, so often times it is missing enough context to make for a useful error message anyway. External dependencies? Yeah, those are tough. Say you have a global structure X. Sure you could export site Y and maybe include structure X, but problems come if you try to load into an instance where there is already a structure X in the global site. How do you reconcile that? Is it a new version? What happens to content in that instance that is using the current X, how could it handle a new X that might be completely different or even exactly the same? These are the kinds of problems that are at the core of the export/import problem, and many of them are issues with missing/incomplete context or conflict resolution. Both of these are really, really tough problems to solve and you'll likely never get one solution that works for everyone. But that brings us back to the content of this blog post - Liferay isn't designed to support content/site promotion, copying, export/import, etc. And rather than trying to force it and fight it, instead you should ditch that idea and embrace the tools that Liferay does support, including staging and now publications. Build your content in the prod environment in staging or publications, publish it to live when it is ready. Liferay _is_ designed to handle this process, so if you embrace it you'll have a much better time with Liferay than if you try and fight it with export/import attempts. 投票するためにはログインが必要です。 次として送信する: キャンセル Fernando Fernandez David H Nebinger 8ヶ月 前 - 編集済み I understand your arguments and also understand the product strategy, but I cannot agree. Still, for all the difficulties in my proposals, there's at least a couple I think should be easy to solve: 1. import should not give up upon first error, and should try to recover as much as possible from the LAR file 2. errors should be made easier to read and the import process should try to help the common user understand what's wrong These, by themselves, would make a big difference in the usefulness of LARs. 投票するためにはログインが必要です。 次として送信する: キャンセル
Fernando Fernandez David H Nebinger 8ヶ月 前 - 編集済み I understand your arguments and also understand the product strategy, but I cannot agree. Still, for all the difficulties in my proposals, there's at least a couple I think should be easy to solve: 1. import should not give up upon first error, and should try to recover as much as possible from the LAR file 2. errors should be made easier to read and the import process should try to help the common user understand what's wrong These, by themselves, would make a big difference in the usefulness of LARs. 投票するためにはログインが必要です。 次として送信する: キャンセル